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.

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.

Bruce Adams wrote:
> Walter Bright Wrote:
>> 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.

Right. But such is worth doing once in a while, because afterwards one tends to implicitly avoid non-portable constructs.

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

I agree that would be a serious impediment.

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

Stack frame layouts might be comparable enough that you can port that bit of code.

Walter Bright wrote:
> Bug fixes. New (and very modest) C++ interface. Library module overhauls by Andrei Alexandrescu. Brad Roberts is working behind the curtain to get phobos development much better organized.
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.022.zip
> 
> http://www.digitalmars.com/d/changelog.html
> http://ftp.digitalmars.com/dmd.2.005.zip

Thanks, Walter. Especially for bug fixes 1488 and 1125.
I suspect the C++ interface stuff will have a big impact on winning over C++ developers.

Don Clugston wrote:
> Thanks, Walter. Especially for bug fixes 1488 and 1125.

You're welcome.

> I suspect the C++ interface stuff will have a big impact on winning over C++ developers.

It's a bit of a shot in the dark. I'm very curious to see how it will work out.

Walter Bright schrieb:
> Bug fixes. New (and very modest) C++ interface. Library module overhauls by Andrei Alexandrescu. Brad Roberts is working behind the curtain to get phobos development much better organized.
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.022.zip
> 
> http://www.digitalmars.com/d/changelog.html
> http://ftp.digitalmars.com/dmd.2.005.zip

The C++ interface is IMO completely useless . Let me quote Walter
"In case that you want D to handle C++ you have to create a complte C++ frontend inside of D" (Not exactly , but I guess I have keeped the meaning)

But this is not the point .
Porting C++ to D is what should be a piece of cake.. In fact it is not..

Instead of enable us to invoke a very small piece of C++ code I would prefer to make D more C++ compatible. (And I really hate C++)

&references ... The Rationales do not say a anything about it
The D "compared to C" just says ... We don't have it.

Struct inheritance
Why we need an *alias here instead of just writing structA : structB;
(*D 2.x future docs.)

C++ op overloading; D is not competitive.

Well there is more. But that's not the point. The point is :  Instead of implementing new and outstanding features, enable us to translate (at least) plain C++ code.

Actually coding C++ code in D  means : rewrite it and make it D-ish, instead of translate it.
This is , simply said shit; and I guess you folks know it.
OkeeDok just my opinion
Bjoern

Walter Bright wrote:
> Don Clugston wrote:
>> Thanks, Walter. Especially for bug fixes 1488 and 1125.
> 
> You're welcome.
> 
>> I suspect the C++ interface stuff will have a big impact on winning over C++ developers.
> 
> It's a bit of a shot in the dark. I'm very curious to see how it will work out.

I think once this feature matures, another article highlighting the feature will go a long way to making them aware of the feature.  It will be interesting to see how/where people plug D into their C++ apps.

-Joel

janderson wrote:
> Walter Bright wrote:
>> Don Clugston wrote:
>>> Thanks, Walter. Especially for bug fixes 1488 and 1125.
>>
>> You're welcome.
>>
>>> I suspect the C++ interface stuff will have a big impact on winning over C++ developers.
>>
>> It's a bit of a shot in the dark. I'm very curious to see how it will work out.
> 
> I think once this feature matures, another article highlighting the feature will go a long way to making them aware of the feature.  It will be interesting to see how/where people plug D into their C++ apps.
> 
> -Joel

Another angle is that *no other language* provides any sort of hook into C++.

"BLS" <nanali@nospam-wanadoo.fr> wrote in message news:fegotb$1l3e$1@digitalmars.com...

> Actually coding C++ code in D  means : rewrite it and make it D-ish,
> instead of translate it.
> This is , simply said shit; and I guess you folks know it.

Wow, harsh.  There are those of us who don't actually spend all of our time translating C++ into D, you know.

Jarrett Billingsley wrote:
> "BLS" <nanali@nospam-wanadoo.fr> wrote in message news:fegotb$1l3e$1@digitalmars.com...
> 
>> Actually coding C++ code in D  means : rewrite it and make it D-ish, instead of translate it.
>> This is , simply said shit; and I guess you folks know it.
> 
> Wow, harsh.  There are those of us who don't actually spend all of our time translating C++ into D, you know. 

I don't recommend anyone actually translate C++ code to D, or C code for that matter. If it's a debugged, working code base, translating to another language is usually a losing proposition.

What matters, though, is being able to interface to that existing code base.