David Heffernan

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.

https://superuser.com/questions/1163753/converting-text-file-to-utf-8-on-windows-command-prompt

And to think that the question was meant to be about ethics.

What can of worms? It has always been easy enough for me. And clearly we do have a dproj in this instance.

That might make it compile, but you'll also need to specify any other options that are non-default. And then update the code that invokes compilation any time you make a change to the project config being compiled. Why not let msbuild do it for you?

As a programmer, you are aware of the issues around invalid data, missing data, etc. The client who provides the specification is often less aware of these issues, and their consequences. In terms of ethics, I would say that as a programmer it is your responsibility to raise the issue with the client. That's part of being a good professional. How the client responds to that is down to them. If they insist on ignoring invalid data, then that is their choice. But you should strongly advise them against that, and if they do insist, then document that this was their choice. In your case it sounds like the ultimate client is not being advised of this, and the culture in your organisation is to do what the client asks without questioning it. That's a slightly different problem. If the decision takers in your organisation are not receptive to best professional practise then there's only so much you can do.

Using msbuild is the simple way to get this done.

Shouldn't you be using msbuild? That's how you make sure that you get all the project settings. Otherwise you have to manually convert all the project settings into the dcc32 arguments. The msbuild rules do all that for you.

These decisions depend very heavily on what type of coding you are doing. In my case it's a numerical code, whose bottlenecks are floating point calculations. So runtime performance is highly important, and Delphi is very poor in this regard. My working assumption is that C++ would be the right choice, at least for the numerical part of the code. But if and when we come to migrate then I'd need to spend a lot of time evaluating options, and I'd look beyond C++ too. This is not to say that I am a big fan of C++.

Yes. Same argument applies. I use delphi because I have a huge code base written in Delphi. If I was starting from scratch I would categorically not use delphi.