Accessing C++ code from D
Hasan Aljudy
hasan.aljudy at gmail.com
Tue May 16 00:57:07 PDT 2006
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.
More information about the Digitalmars-d
mailing list