David Heffernan

I think that post is about accessing a COM object exposed by a .net assembly. But I think that the asker is embedding the .net runtime via its COM interface. So I expect that there is a way to obtain Type and call methods on it, but who wants to scour 32kloc and learn how to use that darn thing. Surely the entire enterprise would be easier by exposing the target code with a .net layer, e.g. a COM wrapper of the target code.

Yes, you are wrong. If you have two threads reading then they are not synchronisation with respect to each other.

Cut it down to a minimal repro. Although it is likely that the answer has been revealed in other comments about the misuse of the lock.

Defect in the code that isn't shown here.

Use classic memory management. obj := TMyObject.Create; try obj.DoSomething; finally obj.Free; end;

They really aren't complex at all to use. Which is my point. You are talking about the implementation details. If you find C# complex then that's on you. Since you declared a few comments back that you didn't really have a sound grasp of C# delegates perhaps you should become knowledgeable on the subject before acting like an expert. Just a thought. Myself, I don't find C# delegates at all complex. It would certainly be pretty convenient if you could use anon methods as event handlers, as you can trivially do in C#. I understand why you can't in Delphi and it's too late to change now. But when you write code in other languages that don't have backwards compatability constraints, it can be irritating when you come back to Delphi.

Er, the complexity is in Delphi with its multiple different procedural types. C# delegates are simple.

Yes to all questions.

It seems to make sense in other languages, like C# to give one example. The very way you talk about it is symptomatic of the problem. Talking about implementation details. Clearly there has to be an implentarion, but programmers by and large want to be shielded from these details.

David is making a good point here. If Emba were starting from scratch here, would they end up with all these different incompatible procedural types? I doubt it.

Personally I think it would take a little more than that to get someone motivated. Just giving you a view from a programmer.

There are a few common reasons why people write software. 1. They get paid to do it. 2. They find intrinsic reward for it. I doubt anybody here not already a developer on this project is going to fit in those categories. Such a person has a steep learning curve, and what would be their reward?

Have you any Delphi experience yourself? What is your involvement in this project?

There's absolutely no reason why you should not do this.

It's important to learn how to try finally is used. Like this resource := acquireResource; try resource.doSomething; finally resource.release; end; I've not use standard names here, but gone for a more conceptual presentation. The key is the order of things.

I'm not sure what the purpose of this post is but it is pretty off topic.

Well, typical C++ code has automatic memory management too using the RAII principle. So that argument falls down I think.

No. The only C++ loop with an interaction statement is for.

I think that the point Angus was making was that he read the text, and did not follow the link. The text seemed to be the first two paragraphs of the blog post, but without mentioning that there was more to be found by following the link. I have to say that I read the post two or three times wondering what it was that you were trying to tell us. Since the text you did include was only part of the story, it would in my view, have been better not to have included any text and just referred us to the offsite link to your blog post. That's at least three people that were confused by the post. Listen to our feedback or not. It's completely voluntary. 😉

🤦🏻‍♀

The Delphi code will look just like the C++ code. I don't think you draw on the canvas at the same time though, the examples show that a lock has to be used.

The C++ for loop, in its general form, is trivially translated into a while loop. So for (init; condition; iteration) statement becomes init; while (condition) { statement; iteration; } It is well worth knowing this if you are in the business of translating pieces of code. So in C++ the for loop is syntactic sugar on top of the while loop. In Delphi also the classic for loop can also be trivially expressed as a while loop. This for loop is simpler than that of C++ but it's still just a while loop (condition tested before body executed) with implicit increment. They Pascal repeat loop is like the C++ do loop. They key being that the condition is at the end of the body rather than the beginning.

We can only dream.......

Load into memory, close, then parse is likely wasteful and risks memory exhaustion. I would urge you to choose the simplest solution that meets your needs, at every decision point.

Why are you so worried about reading from files. It's perfectly normal to open a file, read it, parse as you go, then close. In fact trying to do other than that is just going to create more complexity for you. To what benefit? What is the problem here? What do you see going wrong with the most simple way to read files? It looks like you are inventing a problem where none exists.