On Tue, 29 Nov 2011 16:46:55 +0100, deadalnix <deadal...@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
