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.

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

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.

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.

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

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

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

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

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

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++ code to Java/C#/Eiffel/Ruby/... weren't any easier than this. On the 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