www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Drop extern (C++)

reply BLS <windevguy hotmail.de> writes:
Hi,
I think nearly nobody is using extern (C++) 'cause of it's limits. So 
why not drop it ? IMHO this feature is not a " D2 sales argument", 
instead it's vs. productive.
What do you think ?
Bjoern
May 12 2010
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from BLS (windevguy hotmail.de)'s article
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern

I agree. I personally have no use for it. How much C++ code is there out there that: 1. Doesn't use templates in its external interface. 2. Doesn't use public or protected member fields and virtual functions in the same publicly visible object. (C++'s classes are modeled as interfaces in D) 3. Doesn't use exceptions in its public interface. 4. Can't easily be given a C interface. The questions are, how much complexity does it add to the compiler and is it possible that this interface will become substantially less limited in the future?
May 12 2010
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 12/05/10 13:50, BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern

It should be possible to implement extern(C++) using ctfe/string mixins, as all that needs doing is the name mangling. This is something tools does, allowing you to have the equivalent in D1 [1]. Add to this C++ name mangling doesn't work a lot of the time on linux[2]. I think it's definitely possible to replace it with something in std, possibly based on the code from tools. If it's dropped it does mean a chunk of ddmd will need rewriting, I don't see this as too much of an issue though. [1] http://dsource.org/projects/scrapple/browser/trunk/tools/tools/cpp.d [2] http://d.puremagic.com/issues/show_bug.cgi?id=4059
May 12 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Clipsham wrote:
 On 12/05/10 13:50, BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern


It works well for interfacing to COM.
 It should be possible to implement extern(C++) using ctfe/string mixins, 
 as all that needs doing is the name mangling. This is something tools 
 does, allowing you to have the equivalent in D1 [1].
 
 Add to this C++ name mangling doesn't work a lot of the time on 
 linux[2]. I think it's definitely possible to replace it with something 
 in std, possibly based on the code from tools. If it's dropped it does 
 mean a chunk of ddmd will need rewriting, I don't see this as too much 
 of an issue though.
 
 [1] http://dsource.org/projects/scrapple/browser/trunk/tools/tools/cpp.d
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=4059

If there's a bug in the mangling, please post to bugzilla.
May 12 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 12/05/10 18:55, Walter Bright wrote:
 If there's a bug in the mangling, please post to bugzilla.

I did, see cite note 2 :) I tried to fix it, my quick hack broke most other C++ mangling though, and I've not had time to work on it since... Given the size of the C++ mangling code it shouldn't take you too long to fix it if you get a chance to look though :) [2] http://d.puremagic.com/issues/show_bug.cgi?id=4059 - reposted for convinience
May 12 2010
prev sibling parent reply Don <nospam nospam.com> writes:
BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So 
 why not drop it ? IMHO this feature is not a " D2 sales argument", 
 instead it's vs. productive.
 What do you think ?
 Bjoern
 

There's a much more fundamental problem with it: C++ doesn't support it! You can't compile a file with MSVC and link it to something compiled with g++. Look up my CodeProject article on member function pointers -- every vendor has their own API, and virtually none of them are documented. On Windows, extern(C++) means extern(DMC++), but for me, the only thing I'd want to link to is MSVC. Much more useful would be, as Brad says, to provide a way of specifying the name mangling. If we could do that, we'd be more compatible with C++ than C++ is to itself.
May 12 2010
next sibling parent BLS <windevguy hotmail.de> writes:
On 12/05/2010 21:00, Don wrote:
 BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern

There's a much more fundamental problem with it: C++ doesn't support it! You can't compile a file with MSVC and link it to something compiled with g++. Look up my CodeProject article on member function pointers -- every vendor has their own API, and virtually none of them are documented. On Windows, extern(C++) means extern(DMC++), but for me, the only thing I'd want to link to is MSVC. Much more useful would be, as Brad says, to provide a way of specifying the name mangling. If we could do that, we'd be more compatible with C++ than C++ is to itself.

Given that we have extern (whatever C++) still only virtual methods are available from D. So I doubt that this feature is worth the effort. I see indeed that we have a need for extern (COM). --- ..Detecting extern(C++) implicates that you can use a C++ class out of the box. A new D user gives it a try and after a while he is pretty unsatisfied. This is what I have meant with "not a D Sales argument"
May 12 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article
 BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern

You can't compile a file with MSVC and link it to something compiled with g++. Look up my CodeProject article on member function pointers -- every vendor has their own API, and virtually none of them are documented. On Windows, extern(C++) means extern(DMC++), but for me, the only thing I'd want to link to is MSVC. Much more useful would be, as Brad says, to provide a way of specifying the name mangling. If we could do that, we'd be more compatible with C++ than C++ is to itself.

This brings up another important point: If any implementation of extern(C++) is tied to a specific C++ compiler anyhow (probably the one made by the same people that made the D compiler) then why the heck is it so limited? The rationale for it being so limited was that doing it better would practically require implementing a C++ compiler.
May 12 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 == Quote from Don (nospam nospam.com)'s article
 BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern

You can't compile a file with MSVC and link it to something compiled with g++. Look up my CodeProject article on member function pointers -- every vendor has their own API, and virtually none of them are documented. On Windows, extern(C++) means extern(DMC++), but for me, the only thing I'd want to link to is MSVC. Much more useful would be, as Brad says, to provide a way of specifying the name mangling. If we could do that, we'd be more compatible with C++ than C++ is to itself.


There's a lot more to compatibility than name mangling.
 
 This brings up another important point:  If any implementation of extern(C++)
is
 tied to a specific C++ compiler anyhow

extern(C) is also tied to a particular C compiler.
 (probably the one made by the same people
 that made the D compiler) then why the heck is it so limited?  The rationale
for
 it being so limited was that doing it better would practically require
 implementing a C++ compiler.

May 12 2010
parent Don <nospam nospam.com> writes:
Walter Bright wrote:
 dsimcha wrote:
 == Quote from Don (nospam nospam.com)'s article
 BLS wrote:
 Hi,
 I think nearly nobody is using extern (C++) 'cause of it's limits. So
 why not drop it ? IMHO this feature is not a " D2 sales argument",
 instead it's vs. productive.
 What do you think ?
 Bjoern

You can't compile a file with MSVC and link it to something compiled with g++. Look up my CodeProject article on member function pointers -- every vendor has their own API, and virtually none of them are documented. On Windows, extern(C++) means extern(DMC++), but for me, the only thing I'd want to link to is MSVC. Much more useful would be, as Brad says, to provide a way of specifying the name mangling. If we could do that, we'd be more compatible with C++ than C++ is to itself.


There's a lot more to compatibility than name mangling.

Yes, but the language is powerful enough to deal with everything else.
May 12 2010