David Heffernan

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.

Yes. Same argument applies.

Fossil would be a weird choice. Regardless of how good it is, it's not widespread. git is everywhere, and has so much tooling and resources available. Very hard to see past it.

This __imp_ mangling, IIRC, is used by ms tools when linking using a import lib. Delphi links to DLLs in a different way. Not sure if the difference is important. If it were me I'd compile each source file individually using cl and then link those. Although I don't like to do that very much. It's tempting to be able to link objects statically. But it's fraught with difficulties. It's fiddly. And under x64 you have a further problem. The Delphi compiler doesn't respect the meta data in the object file describing the exception tables. So if exceptions are raised in the linked C code, then it's common for the process to be terminated forcefully. These days I always prefer to link to DLLs using an sxs assembly to avoid problems with dll search paths.

How did you compile the C code?

As for backups with git you can use a cloud repo in addition to any local ones to give you extra redundancy.

The revision control comments are on topic. Revision control is a key part of how you develop new features in an existing code base.

Every effective programmer understands the value of revision control

You only feel the need to develop in such an isolated fashion because you don't use revision control. If you had revision control you'd branch and develop your feature. You'd run your existing tests to prove that you had not damaged existing code. Why do you resist using revision control? It will make you far more productive and effective.