Hello Sergey,
Sun, 7 Dec 2008 07:04:22 +0000 (UTC), John Reimer wrote:
Hello Jason,
Sergey Gromov wrote:
But what's the typical use case for extern(C++) objects ? I think
it's something like this:
extern(C++) class CppInterfaceClass { ... }
extern(C++) CppInterfaceClass create()
{
return new CppInterfaceClass(...);
}
extern(C++) void destroy(CppInterfaceClass obj)
{
delete obj;
}
while extern(C++) will accept that code, but it won't work right.
(Sorry, I've been away for a bit)
I don't think the example is how extern(C++) was designed to work
either.
When used for C++ classes, extern(C++), from what I gather, is
intended to be applied to an /interface/ in the D code, NOT a D
class:
extern(C++) interface Foo {
int foo(int a, b);
}
This interface represents the link to the external C++ class. An
instance of that class is created by the C++ code using a factory
function which D links to in its code (BUT does not implement):
This is one possible use. But the opposite use is also perfectly
possible. The ultimate example of the opposite use is a COM object
implemented in D.
Of course, the documentation on extern(C++) already discusses this.
I just thought it should be made clear here since the prior code
sample implies that the C++ object creation and destruction are done
in D, which it cannot be.
Of course it can. My example wasn't quite correct though. Assuming
your definition of interface Foo, here is the implementation:
extern(C++) interface Foo {
int foo(int a, int b);
}
class FooImpl : Foo {
override int foo(int a, int b) { // implicit extern(C++), correct
VTAB placement
return a + b;
}
}
extern(C++) Foo createFoo() {
return new FooImpl;
}
extern(C++) void destroyFoo(Foo foo) {
delete foo;
}
The only problem with this code is that FooImpl will be GCed as soon
as it leaves the createFoo().
Yes, you are correct here, as far as I understand it. My apologies for forming
the implication that you misunderstood.
-JJR
