DMD 1.022 and 2.005 releases

[Walter Bright]

Frits van Bommel wrote:
> Walter Bright wrote:
>> Bruce Adams wrote:
>>> I was going to post a similar question. I do most of my development
>>> via gcc. I'm only using DMD on windows rather than gdc because its
>>> more reliable (relative to the current state of gdc on cygwin). I
>>> have a lot of current C++ code working under gcc which is one thing
>>> holding me back from adopting D wholesale. A way of supporting gcc
>>> style name mangling as opposed to M$ would be very useful.
>>
>> Supporting gcc name mangling isn't enough, as dmd on Windows doesn't 
>> generate ELF and is incompatible with gcc on many levels.
> 
> Correct me if I'm wrong, but if mangling was taken care of such code 
> could still be linked if for example the C++ code was in a DLL, right?
> Or is the C++ parameter & result passing of mingw/cygwin g++ so 
> different from any method supported by DMD?

There's a lot more to binary compatibility than name mangling. Matching 
the names in a DLL is only the start.

> (IIRC on Linux it's basically the C calling convention with an implicit 
> first 'this' argument for member functions and s/&/*/ on all types)
> 
>> A more practical approach is to recompile your C++ source using DMC++.
> 
> That would depend on how much of it there is to recompile, wouldn't it? :P

It depends on how portably the C++ code is written, not on how much 
there is.

> (Also, the code may use GNU extensions to C++ not present in DMC, 
> requiring more work to port than a simple recompile)

My experiences with non-standard extensions is there's almost never a 
good reason to use them, and this issue is yet another good reason not to.