extern(C++) and struct (constness mangling problem ?)
Martin Nowak
dawg at dawgfoto.de
Tue Nov 29 09:08:55 PST 2011
On Tue, 29 Nov 2011 16:46:55 +0100, deadalnix <deadalnix at gmail.com> wrote:
> Hi,
>
> I did face a problem with extern(C++) again. Now we are talkign about
> const member method for structs. Here is a sample code to trigger the
> error :
>
> extern(C++) {
> struct Fail {
> void method() {}
> void method() const {}
> }
> }
>
> It will generate the error Error: symbol `_ZN4Fail6methodEv' is already
> defined.
>
> Both method are mangled the same way, regardless of constness.
>
> On a more general basis, interfacing to C++ is damn hard to do safely !
> If you put asside some mangling bugs, some D choices make it more
> difficult than necessary.
>
> Notably, it's very difficult to map a C++ POD class with a default
> constructor and copy constructor/assignement overload. struct doesn't
Don't want to be picky, but a struct with default constructor is not a POD.
And yes it is not possible to map all C++ concepts to D.
> allow for default constructor and copy constructor isn't mappable using
> posblit. final class imply an overhead, and are references types (so
> cannot be passed by value).
References only cost you an allocation, the call overhead is practically
inexistent
(I'm not aware of any language that achieves this).
I've recently posted a feasible solution to allocate C++ classes using the
D garbage collector and profit from automatic lifetime management.
https://gist.github.com/1391734
Given that all bugs get sorted out, one can expect three mechanisms to
work.
- Calling free C++ functions and probably non-virtual methods
- Pass POD data forth and back
- Call virtual methods of classes with known vtable layout
Some more things as calling namespace function or certain templates could
probably be provided by a library. But it should suffice to provide zero
overhead
interfacing to most C++ code.
Interfacing QT with it's heavy use of virtual calls, multiple-inheritance
and a custom pre-processor will require an additional simplifying wrapper
layer
on the C++ side.
martin
More information about the Digitalmars-d
mailing list