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