David Heffernan

Premature optimisation

Yes, that's what I envisage

Can't understand why you aren't calling GetMem.

Another option is to use a layered window to add the additional painting. This is very flexible, not limited to panels, doesn't require any changes to the implementation of the controls.

Two things can happen 1. The constructor succeeds and returns a valid object reference. 2. An exception is raised, propagates out of the constructor, and the assignment never happens.

The try finally here isn't protecting the execution of the constructor. It protects against exceptions in the code that runs after the constructor completes, after the try. Look at the code in your post. The try finally is not active when the constructor runs. If an exception is raised in the constructor then the try is never reached. So, yes, you do need the try finally.

I literally wrote class helpers. It will. That's a problem if you are using other helpers for the class. Are you?

This is what class helpers are for. Likewise.

It's possible that the changes you are making to the third party code should be made in your code instead, thus side stepping the problem.

A painful read from a development team that has bitten off way more than it can chew.

Doesn't seem plausible. FileExists doesn't care about spaces. You'll want to do some debugging on a machine that exhibits the behaviour.

could be a long wait

Replace that with AtomicIncrement or the Increment method from System.SyncObjs.TInterlocked

Problem could be how you call the function

It really makes not a lot of difference which vcs you use, compared to not using revision control.

If your program requires the covered code in order to function then I think your code needs to also be GPL. Worth talking to the developer of the code. Often they will dual license for such eventualities.

Probably it is mature now.

Not quite. The default initialisation is outside the function.

You don't get this because the return type is a managed type and so is actually passed as an extra var parameter. So the variable is assumed to have been default initialised outside the function. I'm not trying to defend the compiler design here. The handling of function return variables is a complete mess in my view. They should be passed by value from callee to caller. The whole hidden var param is a weird hack from the ancient past that should never have been done.

https://stackoverflow.com/questions/63111541/omnithread-delphi-many-calls-in-the-same-function For reference, here is the same Q on SO

Adding madExcept or EurekaLog or similar is the obvious way to find out what is going on here.

I'm not denying the existence of the problem. I'm just putting up a flag to say that I believe that in a great many codebases you are very unlikely to encounter it. So, don't get to too stressed about this, and perhaps don't worry about trying to fix the problem unless you know for sure that you are affected by it.

It's pretty unlikely to encounter this issue in real code.

I always turn off stack checking for this reason. Wouldn't it just be better to put it in a DLL?

Just compile the C++ code with options that suppress stack checking. Seriously though, putting all this in a DLL is a far better approach.