David Heffernan

Sometimes it takes strength to say no to some customers.

I dispute that. I don't see anything wrong with a business model that concentrates on enhancing and developing their core market. Imagine what could have been achieved on Windows if all the resource that was used on the new platforms had been spent on Win32 and Win64? Remember also that the vast majority of the income is still from the Windows tools.

Sure it's down to a lack of resources. But that's a consequence of expanding to new platforms. Each additional platform comes with a maintenance cost. That cost is paid for out of revenue. The bulk of the revenue comes from customers that are using the legacy platforms. If Emba continue to neglect their core business (Windows development tools) then eventually customers will look elsewhere.

Kinda galling to realise the effort Emba is putting in for 64 bit mobile and Mac desktop platform support (all minority user bases) and at the same time the Windows compilers (overwhelming majority user base) receive no attention at all. What kind of business model is it to take money of your customers and then spend it on developing functionality that is not useful to the majority of your customers?

Stepping through execution in an interactive debugger is fine for some debugging tasks, but it's just one form of debugging. It's hopeless for debugging threading specific issues. It's the wrong tool. Lots more to debugging than interactive debugger step through.

It's not obscure if you realise that Longint and Longword map to the corresponding C++ types long int and unsigned long int whose size is determined by the platform ABI.

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. 😉