David Heffernan

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. 

6 hours ago, johnnydp said:

I've just read that:

https://community.idera.com/developer-tools/b/blog/posts/c-builder-and-platforms-support

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. 

16 minutes ago, RDP1974 said:

better to wait Embarcadero support for AVX into Delphi asm ... need too much time and easy to do errors

could be a long wait

3 hours ago, Angus Robertson said:

InterlockedIncrement

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

Problem could be how you call the function 

2 hours ago, Mike Torrettinni said:

I assume the combination is good for teams, rather than single developers.

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. 

17 minutes ago, luebbe said:

Although it doesn't get as many updates anymore as it did in the first year.

Probably it is mature now.

9 minutes ago, chkaufmann said:

So just that I get it right: Because my return value is an interface type, the compiler adds something like this as first statement of the method:

 

Result := nil;

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. 

2 hours ago, Arnaud Bouchez said:

It occurred to Eric at least with DWS. He actually monitored it before fixing it.
Of course, he dealt with a language compiler and execution stack, but I guess a lot of other kind of projects may have very tiny objects - if the SOLID principles are properly followed.

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. 

1 hour ago, Stefan Glienke said:

Because msbuild opens an entirely different can of worms and actually requires a dproj - compiling some dpr with dcc is a no brainer

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

16 minutes ago, Stefan Glienke said:

Open cmd, type dcc32 it prints (almost) all parameters. You will find the -NS switch for namespace search path.

So what you do is pass -NSvcl (probably there are some more needed such as Winapi - just take those that a new project in Delphi usually gets)

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. 

40 minutes ago, A.M. Hoornweg said:

Out of interest, which development system would you pick today?

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