DMD 1.022 and 2.005 releases

Bruce Adams tortoise_74 at yeah.who.co.uk
Mon Oct 8 18:23:15 PDT 2007


Walter Bright Wrote:

> 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.
>
I try but you never know how portable your code really isn't until you try a different platform/compiler for the first time. They all have their horrid little quirks mostly because of the preprocessor that D gets rid of.
(Then of course anything in M$ land takes the book and throws it out the window they then write a new book and call it gospel.)

Another problem comes when you have third party libraries in use. As a user of gcc I naturally have made use of a number of linux type,
autoconf configure, make based libraries. I can be confident they will work with gcc but not necessarily with anything else (especially as they tend to written in old fashioned C). I don't want to port them as well.

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

In general yes. But there are a few exceptions to prove the rule. One is access to the stack frame (e.g. for creating stack traces that customers can send back). This is one I actually use but only in one module. It was painful at the time and no doubt it is equally painful every time on each new (or in my case not gnu) compiler. 
There may be other nasty little tricksy things them 'obbits' is keeping from us.

Bruce.



More information about the Digitalmars-d-announce mailing list