www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Accessing C++ code from D

reply Walter Bright <newshound digitalmars.com> writes:
I want to sum up some issues that would have to be resolved in order for 
D code to call some arbitrary C++ code that is presumed to be 
unmodifiable. This list certainly isn't complete, I just write it to 
show the scope of the difficulties involved.

1) D source code is unicode, C++'s is ascii with code pages. Or not. 
It's unspecified. This impacts the contents of string literals.

2) std::string cannot deal with multibyte UTF.

3) C++ has a tag name space. D does not. Some sort of renaming would 
have to happen.

4) C++ code often relies on compiler specific extensions.

5) C++ has namespaces. D has modules. There is no obvious mapping 
between the two.

6) C++ views source code as one gigantic file (after preprocessing). D 
sees source code as a hierarchy of modules and packages.

7) Enum name scoping rules behave differently.

8) C++ code, despite decades of attempts to replace macro features with 
inbuilt ones, relies more heavily than ever on layer after layer of 
arbitrary macros. There is no D analog for token pasting or stringizing.

9) Macro names have global scope across #include files, but are local to 
the gigantic source files.

10) C++ has arbitrary multiple inheritance and virtual base classes. D 
does not.

11) C++ does not distinguish between in, out and inout parameters.

12) The C++ name mangling varies from compiler to compiler.

13) C++ throws exceptions of arbitrary type, not just descendents of Object.

14) C++ overloads based on const and volatile. D does not.

15) C++ overloads operators in significantly different ways - for 
example, operator[]() overloading for lvalue and rvalue is based on 
const overloading and a proxy class.

16) C++ overloads operators like < completely independently of >.

17) C++ overloads indirection (operator*).

18) C++ does not distinguish between a class and a struct object.

19) The vtbl[] location and layout is different between C++ and D.

20) The way RTTI is done is completely different. C++ has no classinfo.

21) D does not allow overloading of assignment.

22) D does not have constructors or destructors for struct objects.

23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.

24) C++ relates classes with the 'friend' system, D uses packages and 
modules.

25) C++ class design tends to revolve around explicit memory allocation 
issues, D's do not.

26) D's template system is very different.

27) C++ has 'exception specifications'.

28) C++ has global operator overloading.

The bottom line is the language features affect the design of the code. 
C++ designs just don't fit with D. Even if you could find a way to 
automatically adapt between the two, the result will be about as 
enticing as the left side of a honda welded to the right side of a camaro.
May 16 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 I want to sum up some issues that would have to be resolved in order for 
 D code to call some arbitrary C++ code that is presumed to be 
 unmodifiable. This list certainly isn't complete, I just write it to 
 show the scope of the difficulties involved.
 
 1) D source code is unicode, C++'s is ascii with code pages. Or not. 
 It's unspecified. This impacts the contents of string literals.
 
 2) std::string cannot deal with multibyte UTF.
 
 3) C++ has a tag name space. D does not. Some sort of renaming would 
 have to happen.
 
 4) C++ code often relies on compiler specific extensions.
 
 5) C++ has namespaces. D has modules. There is no obvious mapping 
 between the two.
 
 6) C++ views source code as one gigantic file (after preprocessing). D 
 sees source code as a hierarchy of modules and packages.
 
 7) Enum name scoping rules behave differently.
 
 8) C++ code, despite decades of attempts to replace macro features with 
 inbuilt ones, relies more heavily than ever on layer after layer of 
 arbitrary macros. There is no D analog for token pasting or stringizing.
 
 9) Macro names have global scope across #include files, but are local to 
 the gigantic source files.
 
 10) C++ has arbitrary multiple inheritance and virtual base classes. D 
 does not.
 
 11) C++ does not distinguish between in, out and inout parameters.
 
 12) The C++ name mangling varies from compiler to compiler.
 
 13) C++ throws exceptions of arbitrary type, not just descendents of 
 Object.
 
 14) C++ overloads based on const and volatile. D does not.
 
 15) C++ overloads operators in significantly different ways - for 
 example, operator[]() overloading for lvalue and rvalue is based on 
 const overloading and a proxy class.
 
 16) C++ overloads operators like < completely independently of >.
 
 17) C++ overloads indirection (operator*).
 
 18) C++ does not distinguish between a class and a struct object.
 
 19) The vtbl[] location and layout is different between C++ and D.
 
 20) The way RTTI is done is completely different. C++ has no classinfo.
 
 21) D does not allow overloading of assignment.
 
 22) D does not have constructors or destructors for struct objects.
 
 23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
 
 24) C++ relates classes with the 'friend' system, D uses packages and 
 modules.
 
 25) C++ class design tends to revolve around explicit memory allocation 
 issues, D's do not.
 
 26) D's template system is very different.
 
 27) C++ has 'exception specifications'.
 
 28) C++ has global operator overloading.
 
 The bottom line is the language features affect the design of the code. 
 C++ designs just don't fit with D. Even if you could find a way to 
 automatically adapt between the two, the result will be about as 
 enticing as the left side of a honda welded to the right side of a camaro.


<3 for you Walter. :)

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
May 16 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Good points, I totally agree.

But .. I still think something can be done.
Yes, it's practically impossible to automatically convert C++ to D. 
However, practically, do we need all of C++, or just a subset?

I claim that there are a lot of great C++ projects out there that don't 
rely too much on templates or operator overloading.

Can C++ classes be converted to D classes? even if not fully?

For starters, the following pattern:

class Foo
{
    type bar( params );
};

type Foo::bar( params )
{
    body;
}

should be easy to convert to:

class Foo
{
    type bar( params )
    {
       body;
    }
}


assuming that no complex C++ features are used in the definitions.


I don't want dmd to implement that. I'm thinking more of a 
conversion-tool that automates these simple things. This can probably 
cut down the effort of manual translation by %50. Although I can't say, 
because I haven't tried a manual translation of C++ code.

I'm thinking of the OGRE project. http://www.ogre3d.org/
It's very well designed and written. I think it uses a good Object 
Oriented style. I would love to see it converted to D.


Walter Bright wrote:

 I want to sum up some issues that would have to be resolved in order for 
 D code to call some arbitrary C++ code that is presumed to be 
 unmodifiable. This list certainly isn't complete, I just write it to 
 show the scope of the difficulties involved.
 
 1) D source code is unicode, C++'s is ascii with code pages. Or not. 
 It's unspecified. This impacts the contents of string literals.
 
 2) std::string cannot deal with multibyte UTF.
 
 3) C++ has a tag name space. D does not. Some sort of renaming would 
 have to happen.
 
 4) C++ code often relies on compiler specific extensions.
 
 5) C++ has namespaces. D has modules. There is no obvious mapping 
 between the two.
 
 6) C++ views source code as one gigantic file (after preprocessing). D 
 sees source code as a hierarchy of modules and packages.
 
 7) Enum name scoping rules behave differently.
 
 8) C++ code, despite decades of attempts to replace macro features with 
 inbuilt ones, relies more heavily than ever on layer after layer of 
 arbitrary macros. There is no D analog for token pasting or stringizing.
 
 9) Macro names have global scope across #include files, but are local to 
 the gigantic source files.
 
 10) C++ has arbitrary multiple inheritance and virtual base classes. D 
 does not.
 
 11) C++ does not distinguish between in, out and inout parameters.
 
 12) The C++ name mangling varies from compiler to compiler.
 
 13) C++ throws exceptions of arbitrary type, not just descendents of 
 Object.
 
 14) C++ overloads based on const and volatile. D does not.
 
 15) C++ overloads operators in significantly different ways - for 
 example, operator[]() overloading for lvalue and rvalue is based on 
 const overloading and a proxy class.
 
 16) C++ overloads operators like < completely independently of >.
 
 17) C++ overloads indirection (operator*).
 
 18) C++ does not distinguish between a class and a struct object.
 
 19) The vtbl[] location and layout is different between C++ and D.
 
 20) The way RTTI is done is completely different. C++ has no classinfo.
 
 21) D does not allow overloading of assignment.
 
 22) D does not have constructors or destructors for struct objects.
 
 23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
 
 24) C++ relates classes with the 'friend' system, D uses packages and 
 modules.
 
 25) C++ class design tends to revolve around explicit memory allocation 
 issues, D's do not.
 
 26) D's template system is very different.
 
 27) C++ has 'exception specifications'.
 
 28) C++ has global operator overloading.
 
 The bottom line is the language features affect the design of the code. 
 C++ designs just don't fit with D. Even if you could find a way to 
 automatically adapt between the two, the result will be about as 
 enticing as the left side of a honda welded to the right side of a camaro.
May 16 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Hasan Aljudy wrote:

 assuming that no complex C++ features are used in the definitions.


The trouble is, they always are. I once looked at automated translation 
of wxWindows, and that's written in a pre-STL pre-template style. No way.

The only C++ code I've been able to convert without much difficulty is 
my own, and that's because I use a gc with my C++ projects, and I 
deliberately write it in a D style. You can see that in the DMD front 
end source.
May 16 2006
parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
 The only C++ code I've been able to convert without much difficulty


is

 my own, and that's because I use a gc with my C++ projects, and I
 deliberately write it in a D style. You can see that in the DMD


front

 end source.


Are there guidelines for writing C/C plus plus in D style?

I'm involved in several freeware projects that I've considered
converting to D when 1.0 is released. Are there things I could be
doing (and not doing) now to facilitate that?
May 16 2006
parent Walter Bright <newshound digitalmars.com> writes:
Lynn Allan wrote:

 The only C++ code I've been able to convert without much difficulty


 is

 my own, and that's because I use a gc with my C++ projects, and I
 deliberately write it in a D style. You can see that in the DMD


 front

 end source.


 
 Are there guidelines for writing C/C plus plus in D style?
 
 I'm involved in several freeware projects that I've considered
 converting to D when 1.0 is released. Are there things I could be
 doing (and not doing) now to facilitate that?


No, there are no guidelines. But you can look at the dmd source and get 
a feel for it.
May 16 2006
prev sibling next sibling parent reply Brad Anderson <brad dsource.org> writes:
Hasan Aljudy wrote:

 I'm thinking of the OGRE project. http://www.ogre3d.org/
 It's very well designed and written. I think it uses a good Object
 Oriented style. I would love to see it converted to D.


I don't believe it's been touched in a while, but Sinbad at dsource.org is
exactly this.

BA

http://svn.dsource.org/projects/sinbad/trunk
May 16 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Brad Anderson wrote:

 Hasan Aljudy wrote:
 

I'm thinking of the OGRE project. http://www.ogre3d.org/
It's very well designed and written. I think it uses a good Object
Oriented style. I would love to see it converted to D.


 
 
 I don't believe it's been touched in a while, but Sinbad at dsource.org is
 exactly this.
 
 BA
 
 http://svn.dsource.org/projects/sinbad/trunk


Yea, I know, but it seems manual translation of OGRE isn't so practical; 
at least not if it's a one-man effort.
May 16 2006
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Hasan Aljudy wrote:


 I'm thinking of the OGRE project. http://www.ogre3d.org/
 It's very well designed and written. I think it uses a good Object
 Oriented style. I would love to see it converted to D.


Yes, the Sinbad project at DSource was supposed to be an implementation of
OGRE in D. Even if OGRE is fairly clean, it use quite a bit of MI which
isn't easily solvable in D without changing how things should work. Also,
OGRE is heavily relying upon plugins, which currently are somewhat
difficult to do in D, although DDL is getting there. It is also using a bit
of STL, so all in all I suspect it is a typical C++ library that is
typically difficult to convert to D without huge manual efforts.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
May 16 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Lars Ivar Igesund wrote:

 Hasan Aljudy wrote:
 
 

I'm thinking of the OGRE project. http://www.ogre3d.org/
It's very well designed and written. I think it uses a good Object
Oriented style. I would love to see it converted to D.


 
 
 Yes, the Sinbad project at DSource was supposed to be an implementation of
 OGRE in D. Even if OGRE is fairly clean, it use quite a bit of MI which
 isn't easily solvable in D without changing how things should work. Also,
 OGRE is heavily relying upon plugins, which currently are somewhat
 difficult to do in D, although DDL is getting there. It is also using a bit
 of STL, so all in all I suspect it is a typical C++ library that is
 typically difficult to convert to D without huge manual efforts.
 


sigh :(

oh well, maybe a better and faster engine can be done in D, from scratch!
May 16 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:e4d1i8$snf$1 digitaldaemon.com...

 sigh :(

 oh well, maybe a better and faster engine can be done in D, from scratch!


I'm working on it, I'm working on it!  ;)

I was surprised to look at the OGRE page and see so many features that it 
has that nonagon has as well.. of course, OGRE is much more mature, 
API-independent, and therefore cross-platform, but.. I'm working on it!
May 16 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Jarrett Billingsley wrote:

 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
 news:e4d1i8$snf$1 digitaldaemon.com...

 sigh :(

 oh well, maybe a better and faster engine can be done in D, from scratch!


 
 I'm working on it, I'm working on it!  ;)
 
 I was surprised to look at the OGRE page and see so many features that it 
 has that nonagon has as well.. of course, OGRE is much more mature, 
 API-independent, and therefore cross-platform, but.. I'm working on it! 
 
 


Do you have plans to abstract away from DirectX?

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
May 16 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kyle Furlong" <kylefurlong gmail.com> wrote in message 
news:e4dbp2$1brv$1 digitaldaemon.com...


 Do you have plans to abstract away from DirectX?


Perhaps once I've become truly comfortable with DirectX ;)

Though the engine design itself is kind of.. automatically moving itself 
away from platform-dependence.  I'm not consciously doing it, but as I 
reorganize the engine, it just ends up that way.  For example, so far 
working on R5, I've abstracted mesh data and loading, I've abstracted some 
of the OS interfaces, and I've clearly delineated the two pipelines, so all 
the common code would be pretty much implementation-independent.  So, with 
maybe one more major release of nonagon (R6, one after the next), it might 
be abstracted enough that making a platform-independent version of it 
wouldn't be too hard.
May 16 2006
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Jarrett Billingsley wrote:

 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
 news:e4d1i8$snf$1 digitaldaemon.com...
 

sigh :(

oh well, maybe a better and faster engine can be done in D, from scratch!


 
 
 I'm working on it, I'm working on it!  ;)
 
 I was surprised to look at the OGRE page and see so many features that it 
 has that nonagon has as well.. of course, OGRE is much more mature, 
 API-independent, and therefore cross-platform, but.. I'm working on it! 
 
 


Good to know. :)

I would love to participate in such a project, but my knowledge of 
graphics APIs is next to nothing.

Do you have a website for the project? can you possibly put it on dsource?
May 16 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:e4dcel$1d2v$1 digitaldaemon.com...


 Good to know. :)

 I would love to participate in such a project, but my knowledge of 
 graphics APIs is next to nothing.


Pah, it's not hard to pick up.. just set a couple states, load some data, 
and draw ;)


 Do you have a website for the project? can you possibly put it on dsource?


I have a download thing, at 
http://jamesdunne.no-ip.org/nonagon/projects.php, but no real project page. 
I've been planning on making it open-source as of late, since I can't seem 
to find the time/drive to work on it for long periods of time.  Right now, 
it's in a very transitional state, as I've been reworking a lot of the 
internals of the engine, splitting apart the two pipelines, cleaning up 
dependencies, refactoring some code, and working on getting model animation 
working (which it is, for the most part, at least in the fixed-function 
pipeline).  But I'd still like to make a page for it on dsource or 
something.
May 16 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Jarrett Billingsley wrote:

 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
 news:e4dcel$1d2v$1 digitaldaemon.com...
 

 Good to know. :)

 I would love to participate in such a project, but my knowledge of 
 graphics APIs is next to nothing.


 
 Pah, it's not hard to pick up.. just set a couple states, load some data, 
 and draw ;)
 

 Do you have a website for the project? can you possibly put it on dsource?


 
 I have a download thing, at 
 http://jamesdunne.no-ip.org/nonagon/projects.php, but no real project page. 
 I've been planning on making it open-source as of late, since I can't seem 
 to find the time/drive to work on it for long periods of time.  Right now, 
 it's in a very transitional state, as I've been reworking a lot of the 
 internals of the engine, splitting apart the two pipelines, cleaning up 
 dependencies, refactoring some code, and working on getting model animation 
 working (which it is, for the most part, at least in the fixed-function 
 pipeline).  But I'd still like to make a page for it on dsource or 
 something. 
 
 


I would be interested in making this a premier game solution in D with 
you. Dsource would be the way to go to collaborate.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
May 16 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kyle Furlong" <kylefurlong gmail.com> wrote in message 
news:e4decl$1fhe$1 digitaldaemon.com...


 I would be interested in making this a premier game solution in D with 
 you. Dsource would be the way to go to collaborate.


That would be sweet.  Of course, I'd have to learn about things like code 
repository systems..
May 16 2006
parent clayasaurus <clayasaurus gmail.com> writes:
Jarrett Billingsley wrote:

 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:e4decl$1fhe$1 digitaldaemon.com...
 

 I would be interested in making this a premier game solution in D with 
 you. Dsource would be the way to go to collaborate.


 
 That would be sweet.  Of course, I'd have to learn about things like code 
 repository systems.. 
 
 


That'll take all of 5 minutes ;)
May 16 2006
prev sibling parent sailormoontw <sailormoontw_member pathlink.com> writes:
In article <e4dclr$1d7m$2 digitaldaemon.com>, Jarrett Billingsley says...

I have a download thing, at 
http://jamesdunne.no-ip.org/nonagon/projects.php, but no real project page. 
I've been planning on making it open-source as of late, since I can't seem 
to find the time/drive to work on it for long periods of time.  Right now, 
it's in a very transitional state, as I've been reworking a lot of the 
internals of the engine, splitting apart the two pipelines, cleaning up 
dependencies, refactoring some code, and working on getting model animation 
working (which it is, for the most part, at least in the fixed-function 
pipeline).  But I'd still like to make a page for it on dsource or 
something. 


Thanks Jarrett, I know this project and I am waiting the RC5, and you know the
D3DX9 currently has a version of 28. It's a wonderful thing if you can upgrade
newer version of nonagon.
May 16 2006
prev sibling next sibling parent Olaf Pohlmann <op nospam.org> writes:
Walter Bright wrote:

 1) [...] 28)


This should go into the FAQ to avoid lengthy discussions in the future. 
After reading these groups for a couple of months I find it already hard 
enough to follow up with all the traffic. And I'm a bit confused that 
people keep popping up making bold requests on a language below version 
1.0. Healthy growth is slow and steady, just what I observe with D. I'm 
looking forward to the next couple of months...


op
May 16 2006
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
explain the c++ linkage problem a litte bit more detailed:

for example:

"have you ever tried to link your visualc++, borlandc++ and other (c++ 
compilers) produced libs together - do it and you will see how (realy) 
well the c++ abi is standarized :-)"

ciao dennis
May 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
dennis luehring wrote:

 explain the c++ linkage problem a litte bit more detailed:
 
 for example:
 
 "have you ever tried to link your visualc++, borlandc++ and other (c++ 
 compilers) produced libs together - do it and you will see how (realy) 
 well the c++ abi is standarized :-)"


DMC++ (in a former life) was designed to be ABI compatible with 
Microsoft C++, and it was for a while, until Microsoft changed their 
ABI. Sigh.
May 16 2006
parent dennis luehring <dl.soluz gmx.net> writes:
 DMC++ (in a former life) was designed to be ABI compatible with 
 Microsoft C++, and it was for a while, until Microsoft changed their 
 ABI. Sigh.


i know - thats why i wrote this FAQ-Sample-Text (just copy paste :-))
May 16 2006
prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:

 I want to sum up some issues that would have to be resolved in order for 
 D code to call some arbitrary C++ code that is presumed to be 
 unmodifiable. This list certainly isn't complete, I just write it to 
 show the scope of the difficulties involved.
 
 1) D source code is unicode, C++'s is ascii with code pages. Or not. 
 It's unspecified. This impacts the contents of string literals.
 
 2) std::string cannot deal with multibyte UTF.
 
 3) C++ has a tag name space. D does not. Some sort of renaming would 
 have to happen.
 
 4) C++ code often relies on compiler specific extensions.
 
 5) C++ has namespaces. D has modules. There is no obvious mapping 
 between the two.
 
 6) C++ views source code as one gigantic file (after preprocessing). D 
 sees source code as a hierarchy of modules and packages.
 
 7) Enum name scoping rules behave differently.
 
 8) C++ code, despite decades of attempts to replace macro features with 
 inbuilt ones, relies more heavily than ever on layer after layer of 
 arbitrary macros. There is no D analog for token pasting or stringizing.
 
 9) Macro names have global scope across #include files, but are local to 
 the gigantic source files.
 
 10) C++ has arbitrary multiple inheritance and virtual base classes. D 
 does not.
 
 11) C++ does not distinguish between in, out and inout parameters.
 
 12) The C++ name mangling varies from compiler to compiler.
 
 13) C++ throws exceptions of arbitrary type, not just descendents of 
 Object.
 
 14) C++ overloads based on const and volatile. D does not.
 
 15) C++ overloads operators in significantly different ways - for 
 example, operator[]() overloading for lvalue and rvalue is based on 
 const overloading and a proxy class.
 
 16) C++ overloads operators like < completely independently of >.
 
 17) C++ overloads indirection (operator*).
 
 18) C++ does not distinguish between a class and a struct object.
 
 19) The vtbl[] location and layout is different between C++ and D.
 
 20) The way RTTI is done is completely different. C++ has no classinfo.
 
 21) D does not allow overloading of assignment.
 
 22) D does not have constructors or destructors for struct objects.
 
 23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
 
 24) C++ relates classes with the 'friend' system, D uses packages and 
 modules.
 
 25) C++ class design tends to revolve around explicit memory allocation 
 issues, D's do not.
 
 26) D's template system is very different.
 
 27) C++ has 'exception specifications'.
 
 28) C++ has global operator overloading.
 
 The bottom line is the language features affect the design of the code. 
 C++ designs just don't fit with D. Even if you could find a way to 
 automatically adapt between the two, the result will be about as 
 enticing as the left side of a honda welded to the right side of a camaro.


And if that wasn't enough to turn you off to the idea, then you could 
try to use Lightweight C++ 
<http://students.ceid.upatras.gr/~sxanth/lwc/> to translate your 
extremely-dumbed-down C++ code into C code.  For best interoperability 
with DMD, you'd have to compile the C code with DMC.

Slight caveat: "To compile the generated C you need gcc or another 
compiler with support for: C99 designators, compound statements in 
expressions and typeof."  Does DMC fit this bill?

Disclaimer:  I realize this is to the point of absurdity, but I would 
try to make the point that it is no more absurd than to expect any more 
out of a language (C++) that has designed itself into a corner.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
May 16 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
James Dunne wrote:

 Disclaimer:  I realize this is to the point of absurdity, but I would
 try to make the point that it is no more absurd than to expect any more
 out of a language (C++) that has designed itself into a corner.


That's right. I wouldn't be surprised if automatic conversion of C++

other hand converting all these to D seems to be almost trivial,
although creating such a tool for the task is admittedly a bit time
consuming.

-- 
Jari-Matti
May 16 2006
parent Walter Bright <newshound digitalmars.com> writes:
Jari-Matti Mäkelä wrote:

 James Dunne wrote:

 Disclaimer:  I realize this is to the point of absurdity, but I would
 try to make the point that it is no more absurd than to expect any more
 out of a language (C++) that has designed itself into a corner.


 
 That's right. I wouldn't be surprised if automatic conversion of C++

 other hand converting all these to D seems to be almost trivial,
 although creating such a tool for the task is admittedly a bit time
 consuming.



Ruby definitely not, as Ruby relies on dynamic typing and dynamic code 
modification.

I do agree, however, that C++ has rather thoroughly wedged itself into a 
corner. One only has to look at the proposals for C++0x to see that.
May 16 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 I want to sum up some issues that would have to be resolved in order for 
 D code to call some arbitrary C++ code that is presumed to be 
 unmodifiable.


I seriously plead that we don't even think about this before D 1.5!

Please.
May 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 I want to sum up some issues that would have to be resolved in order 
 for D code to call some arbitrary C++ code that is presumed to be 
 unmodifiable.


 
 I seriously plead that we don't even think about this before D 1.5!
 
 Please.


LOL! It isn't going to happen. But it comes up often enough that it's 
worth writing some explanation down.
May 16 2006
parent reply Rémy Mouëza <Rémy_member pathlink.com> writes:
IMO, Accessing C++ code from D is not a feature that should be supported by the
D compiler.
There has been some attempts to build C++ wrapper generators for D: swig, a
macro system and I even made one myself (but the memory management is ugly). We
just need  C void * pointers. There are (and will be) brilliant people who
(will) make great tools for D. The impatients (like me) can try to link with the
ones they used in C++. We need time. 
I also tried to make a C++ to D translator by modifying Peri's Hankey d2d
language machine script. It can handle small sized code and output quite
syntactically correct D code but the semantic is incorrect, especially for
templates because of the overwhelming "template <T>" syntax. I've given up for
the moment. A translator is not enough: a C++ compiler to D could eventually do
it but sounds like nonsense.
Being a successor of C++ doesn't means that D should support it. Java does not
support C++ and this lack has not prevent it to spread.
May 18 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
IMO, Accessing C++ code from D is not a feature that should be supported by the
 compiler.
There has been some attempts to build C++ wrapper generators for D: swig, a
macro system and I even made one myself (but the memory management is ugly). We
just need  C void * pointers. There are (and will be) brilliant people who
(will) make great tools for D. The impatients (like me) can try to link with
the ones they used in C++. We need time. 


Swig works well for what it does.  Generally however you have to devote quite a
bit of time to a swig wrapper to keep it in sync as well.


I also tried to make a C++ to D translator by modifying Peri's Hankey d2d
language machine script. It can handle small sized code and output quite
syntactically correct D code but the semantic is incorrect, especially for
templates because of the overwhelming "template <T>" syntax. I've given up for
the moment. A translator is not enough: a C++ compiler to D could eventually
>do it but sounds like nonsense.


I don't think a C++ to D translator is possible or even a good idea.  Cpp simply
would not translate into equivalent D idioms except in trivial instances.  That
being said, Cpp/D interop is a completely different animal.  With interop,
you're not trying to translate one idiom into another, instead you're just
making it easier for each to co-exist, and to be able to easily access the
functionality of one from within the other without rewriting.

Microsoft's Cpp/CLI is an excellent example of how interop can work.  Cpp is not

within a traditional Cpp program in a reasonably effective manner, and without


Cpp interop is not "translation".  It would be limited to being able to access
members of a cpp class, call cpp member functions, use C and Cpp macros, and
inline C or Cpp code.  Parsing of Cpp headers would be handled by the Cpp
compiler's parser using GCC-XML.  And compiling of Cpp interop code for
templates, macros, and other complex Cpp elements would be handled by the Cpp
compiler, and accessed in D through C functions.  

For example, with this system, the issues you had with templates simply don't
arise because templates are not converted into D template code, they are
specialized nto standard Cpp classes and compiled with the Cpp compiler, and
those classes are called from the D/Cpp interop system.


Being a successor of C++ doesn't means that D should support it. Java does not
support C++ and this lack has not prevent it to spread.


Yes, and yes.  

Yes it certainly should support interop if there is any real intention of being
a successor to Cpp.  

And Yes, interop issues are part of the reason why the new .NET system is




Outside of the D forums in the general programming world these issues are not
really controversial.  They are considered self evident and obvious.  This is
why D is not a real alternative to Cpp or C for most programmers.  The successor
to Cpp will not be D, it will be Cpp 0x.
May 18 2006
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Ben Cooley wrote:


 
 Yes it certainly should support interop if there is any real intention of being
 a successor to Cpp.  


No it shouldn't. D is trying to break away from C++, not extend it.


 
 And Yes, interop issues are part of the reason why the new .NET system is






that multiple languages could share the same resources and talk to each 
other. D had no such design goals.


 
 Outside of the D forums in the general programming world these issues are not
 really controversial.  They are considered self evident and obvious.  This is
 why D is not a real alternative to Cpp or C for most programmers.  


All of the D community comes from /outside/ of the D community, and most 
of us still live and work there. In my world, what you are saying just 
isn't true. You focus too much on C++, your circumstances, and the 
circumstances of people you know. The general programming world is much 
larger than that. I don't give a rat's ass about C++ interoperability. 
Most people I know wouldn't give a rat's ass about it either. I know C++ 
programmers who would happily switch over and use D for all of their new 
projects once their bosses approve it.

But why should would you stop with C++ interoperability? What all of the 
Java code bases out there? Surely they would be more likely to come to D 

the VB programmers? Why not just develop our own Common Language 
Interface? Because that's not the design goal behind D.

D isn't meant to just be a replacement for C++. It melds the features of 
several languages, along with new ideas, into something that is an 
excellent /alternative/ to many existing languages, not just C++. C++ 
interoperability would only be useful to a small subset of potential D 
users, not the masses to whom you claim it is self evident.

Obviously, D isn't going to be suited to every project. If you rely on a 
few million lines of C++, Java, or other code (besides C), then D isn't 
the best solution for leveraging that code base. But I just don't see 
how that is going to be a deal breaker for D's acceptance. I think the 
problem is much smaller than you let on.
May 18 2006
prev sibling parent James Dunne <james.jdunne gmail.com> writes:
Ben Cooley wrote:

[snip]
 
 And Yes, interop issues are part of the reason why the new .NET system is



 




C code through runtime marshalling.  It does not interop with native C++ 
code - such code has to be recompiled through Microsoft's "Managed 
Extensions for C++" compiler, after much tinkering albeit.

I'll bet that if you were to take the time to convert your existing C++ 
library over to .NET you'd find you'd spend the same amount of time as 
you would creating a C API wrapper around such code for D to use.

-- 
Regards,
James Dunne
May 18 2006