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


 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.


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


 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.




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


 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.




 
 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