www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interfacing with XPCOM

reply John Reimer <terminal.node gmail.com> writes:
As the title suggests, this post is about D interfaces, specifically as
supported 
in D 1.0.  

Here's some background:

I've been working on porting the SWT Browser package to DWT (on Linux) over 
the last few months.  I'm happy to say that I've mostly succeeded despite 
some rather annoying problems.  The important issues have been ironed out. 
 What remains now is to get down to some heavy debugging sessions.

SWT implements its Browser code based on the mozilla XPCOM interface.  What 
this means is that in order to use the SWT Browser in your project, you need 
to install a mozilla package called XULRunner that provides all the components 
that make up a working browser.  XULRunner is basically the Mozilla Team's 
way of separating the internals of Mozilla Firefox into a shared package 
that serves any number of applications that want to embed browser components. 
 As of Firefox 3.0, the Mozilla Foundation has moved to this XPCOM component 
server system; it seems that they now include the XULRunner package within 
the Firefox installation instead of making it an integrated component of 
the browser.

Obviously this scheme is useful for all sorts of apps that want to embed 
a comprehensive browser.  The only requirement is that development language 
know how to interface to the Mozilla components.  So the key here is that 
a language must be compatible with XPCOM.

This is no problem for D on windows machines because D provides a mechanism 
of direct COM interface support on that platform.  XPCOM happens to be binary 
compatible with the vtable layout of the COM structure, so, on windows, all 
one has to do is alias the XPCOM's base interface nsISupports to the COM 
IUknown.  The D compiler takes care of the rest since it automatically adjusts 
the vtable when it sees a reference to the IUnknown COM type.

But how does one do this on Linux?  Can we use D to interface with XPCOM 
there?  The problem is that this will not work on Linux since COM has no 
meaningful implementation on the platform primarily because all COM components 
are declared extern(Windows) internally by the D compiler.   This would appear 
to mean that Linux is left out in the cold when it comes to interfacing with 
anything like XPCOM.  D interfaces obviously won't work because they are 
constitute a new type, independent of any relationship to any other language 
interface (D intefaces insert a vtable entry at index 0 that references RTTI).

There is, in fact, a solution for Linux:

We can use the COM interface alias technique just as we would on windows.

[code]

alias IUknown nsISupports;

[/code]

Even on linux, the D compiler will create a COM clean vtable with windows 
calling convention for the methods.  You don't actually notice that the
compiler 
has done this until you try to implement some classes based on the interface, 
at which point the compiler protests loudly.  Now on linux, we need to get 
rid of the windows calling convention in order to make the interfaces XPCOM 
compatible.  The best way to do this is to directly override the compiler 
by declaring each interface method extern(C); this is something XPCOM wants 
to see.

[code]

interface IUnknown
{
    static const char[] IID_STR = NS_ISUPPORTS_IID_STR;
    static const nsIID IID = NS_ISUPPORTS_IID;

extern(System):
    nsresult QueryInterface( nsIID* uuid, void **result);
    nsrefcnt AddRef();
    nsrefcnt Release();
}

[/code]

I've used extern(System) to demonstrate a quick way to do this for the
particular 
platform so the code is portable.  Now we have a simple COM interface with 
extern(C) calling convention that will interface acceptably with Linux XPCOM.

There's still a problem here, however.  Since we are using IUnknown, the 
D compiler is going to secretly force all /class/ methods that implement 
the contract methods to also use extern(Windows).  So within any class that 
implements the interface, we also have to apply the extern(System) decoration:

[code]

class A : nsISupports {
    extern(System) nsresult QueryInterface( nsIID* uuid, void **result) {} 
   
    ...
}

[/code]

But what about the class methods that don't implement the interface?  Well, 
they have to be explicitly declared extern(D) in order to keep the compiler 
from complaining again.

[code]

class A : nsISupports {
    extern(System) nsresult QueryInterface( nsIID* uuid, void **result) {} 
   
    ...
    extern(D) void handleFolderEvent( Event event );
}

[/code]

The above code worked in porting the Browser code to DWT specifically for 
D version 1.0.  But I have to admit that I remain a little uncomfortable 
implementing the fix this way.  It's a hack.  Unfortunately, it's the only 
way I know that simply and effectively solves this problem.  

Here are a couple of thoughts I have:

(1) I'm wondering if the implicit COM support (triggered by the IUnknown 
symbol only) implemented in D is such a good idea.  Would such a feature 
be more correctly supported as a Pragma wherever an interface vtable type 
is augmented in a system specific way?  pragma("COM") {} or something to 
that effect.

(2) As an alternate solution to my trick with COM on linux, there is also 
the option of using extern(C++), except that it only exists in D 2.0.  I 
think using extern(C++) might work in this situation because mozilla XPCOM 
interfaces are often represented in C++ using single inheritance C++ class 
structures.  The vtables should match unless I'm missing some important detail. 
 Porting extern(C++) to D 1.0 should not constitute a spec change, and it 
could mean simpler support for Mozilla XPCOM without ugly workarounds.  Does 
this sound reasonable?

For more information, I've also covered the same material here:

http://www.dsource.org/projects/dwt/wiki/PortingJournal

Here's a link to the Walter's discription of D 2.0 Interfaces and the addition 
of extern(C++) along with its caveats:

http://www.digitalmars.com/d/2.0/cpp_interface.html

Notice that in the above link Walter says COM only works on windows. ;)

-JJR
Nov 30 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
So are you saying that XPCOM will work on Linux with D if only the 
extern(Windows) was actually extern(C++) ?
Nov 30 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?
 

Yes, I think so. But I should probably test the theory with dmd 2.0 first just to make sure. This is just about over my head since I'm not too familiar with C++ internals. In terms of XPCOM, I believe that when an interface is assigned an implementation pointer and the interface method is called, the most important detail is that the /parameter/ signature at a specific vtable index match that of the implementation's at the same index: that is, the method names are not important except as an alias for client to use; it is assumed that the interface methods will match the calling convention and argument types of the implementation which was assigned to it). So my question would be, in terms /calling conventions/ in an /interface/ (not a class), does extern(System) differ in any way from extern(C++). Does a "this" pointer get prepended to the argument list of a C++ method call? I apologize if this is an ignorant question. I'm almost clueless here. I'm assuming that the only difference in the extern(C++) is that it: (1) changes the interface to have a "normal" vtable (as XPCOM needs) and (2) allows for a system calling convention (method name not being important other than that the parameters of interface and implementation match). -JJR
Nov 30 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 Hello Walter,
 
 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?

Yes, I think so. But I should probably test the theory with dmd 2.0 first just to make sure. This is just about over my head since I'm not too familiar with C++ internals. In terms of XPCOM, I believe that when an interface is assigned an implementation pointer and the interface method is called, the most important detail is that the /parameter/ signature at a specific vtable index match that of the implementation's at the same index: that is, the method names are not important except as an alias for client to use; it is assumed that the interface methods will match the calling convention and argument types of the implementation which was assigned to it). So my question would be, in terms /calling conventions/ in an /interface/ (not a class), does extern(System) differ in any way from extern(C++). Does a "this" pointer get prepended to the argument list of a C++ method call? I apologize if this is an ignorant question. I'm almost clueless here. I'm assuming that the only difference in the extern(C++) is that it: (1) changes the interface to have a "normal" vtable (as XPCOM needs) and (2) allows for a system calling convention (method name not being important other than that the parameters of interface and implementation match).

The system linkage was devised to match the Microsoft "syscall" convention. It really has no meaning on linux, so we can make it whatever it needs to be. The C++ convention is designed to match whatever C++ does on the target platform. Since Linux doesn't have any Windows or System calling convention, it would seem that C++ is the one.
Nov 30 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 John Reimer wrote:
 
 Hello Walter,
 
 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?
 

first just to make sure. This is just about over my head since I'm not too familiar with C++ internals. In terms of XPCOM, I believe that when an interface is assigned an implementation pointer and the interface method is called, the most important detail is that the /parameter/ signature at a specific vtable index match that of the implementation's at the same index: that is, the method names are not important except as an alias for client to use; it is assumed that the interface methods will match the calling convention and argument types of the implementation which was assigned to it). So my question would be, in terms /calling conventions/ in an /interface/ (not a class), does extern(System) differ in any way from extern(C++). Does a "this" pointer get prepended to the argument list of a C++ method call? I apologize if this is an ignorant question. I'm almost clueless here. I'm assuming that the only difference in the extern(C++) is that it: (1) changes the interface to have a "normal" vtable (as XPCOM needs) and (2) allows for a system calling convention (method name not being important other than that the parameters of interface and implementation match).

convention. It really has no meaning on linux, so we can make it whatever it needs to be. The C++ convention is designed to match whatever C++ does on the target platform. Since Linux doesn't have any Windows or System calling convention, it would seem that C++ is the one.

So extern(System) does not translate to extern(C)? Does that mean that all extern(System)'s in my code are defaulting to extern(D)? That'd be a shocker to me. :) If that's true, it would certainly change my understanding of what I thought was making my code work. :D -JJR
Nov 30 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 So extern(System) does not translate to extern(C)?   Does that mean that 
 all extern(System)'s in my code are defaulting to extern(D)?
 
 That'd be a shocker to me. :)  If that's true, it would certainly change 
 my understanding of what I thought was making my code work. :D

No, extern(System) does on linux just what it does on windows, it's just that there's no point to it on linux.
Nov 30 2008
next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 John Reimer wrote:
 
 So extern(System) does not translate to extern(C)?   Does that mean
 that all extern(System)'s in my code are defaulting to extern(D)?
 
 That'd be a shocker to me. :)  If that's true, it would certainly
 change my understanding of what I thought was making my code work. :D
 

just that there's no point to it on linux.

Okay. I've found it very useful on linux, especially when I'm doing windows/linux library projects. It does simplify things greatly because you don't have to declare extern(C) and extern(Windows) under different version statements for projects that are going to support windows and linux. And, at least, it is different than extern(D) because it removes the name mangling. So I'd say it has important usefulness even on Linux. -JJR
Nov 30 2008
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:
 John Reimer wrote:
 So extern(System) does not translate to extern(C)?   Does that mean 
 that all extern(System)'s in my code are defaulting to extern(D)?

 That'd be a shocker to me. :)  If that's true, it would certainly 
 change my understanding of what I thought was making my code work. :D

No, extern(System) does on linux just what it does on windows, it's just that there's no point to it on linux.

I thought the whole point of extern(System) was to provide a workaround when... version(Windows) extern(Windows): else extern(C): ...stopped working ?!? from spec: "System is the same as Windows on Windows platforms, and C on other platforms"
Nov 30 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Tomas,

 Walter Bright wrote:
 
 John Reimer wrote:
 
 So extern(System) does not translate to extern(C)?   Does that mean
 that all extern(System)'s in my code are defaulting to extern(D)?
 
 That'd be a shocker to me. :)  If that's true, it would certainly
 change my understanding of what I thought was making my code work.
 :D
 

just that there's no point to it on linux.

workaround when... version(Windows) extern(Windows): else extern(C): ...stopped working ?!? from spec: "System is the same as Windows on Windows platforms, and C on other platforms"

Yeah, that was it. I think we just had some miscommunication going on. -JJR
Nov 30 2008
parent reply Kagamin <spam here.lot> writes:
G++ uses C++ abstract class for nsISupports, so its methods calling convention
is C++ as implemented by g++:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Compatibility.html
Dec 01 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Kagamin,

 G++ uses C++ abstract class for nsISupports, so its methods calling
 convention is C++ as implemented by g++:
 
 http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Compatibility.html
 

Yes, I had a peek at the XULRunner SDK, and it looked something like you say. Thank you for the link. It looks like the most significant details of the C++ ABI in this case (for XPCOM to D interfacing) are: (1) name mangling (which won't be an issue in XPCOM from what I understand) (2) layout and alignment of virtual tables (*important and effectively handled by extern(C++) /IF/ the C++ classes meet the criteria specified in the D spec). It would be nice if extern(C++) were still ported to D 1.0, but the other alternative of enabling extern(System) in COM support (instead of extern(Windows) ) will also work. Extern(C++) might turn out to be just another alternative which would be nice to have. -JJR
Dec 01 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 It would be nice if extern(C++) were still ported to D 1.0, but the 
 other alternative of enabling extern(System) in COM support (instead of 
 extern(Windows) ) will also work.

Unfortunately, extern(C++), even if ported to D1, will not work for COM objects. COM objects, to be compatible with Windows, need to be the Windows calling convention.
Dec 01 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 John Reimer wrote:
 
 It would be nice if extern(C++) were still ported to D 1.0, but the
 other alternative of enabling extern(System) in COM support (instead
 of extern(Windows) ) will also work.
 

COM objects. COM objects, to be compatible with Windows, need to be the Windows calling convention.

Er... Yes, actually my statement above was meant to emphasize the potential usefulness of extern(C++) for XPCOM support on Linux among many things. That said, I'm guessing that even extern(C++) would work fine for COM support on windows if one directly declares the interface methods with extern(Windows) attribute. Similar to COM, C++ XPCOM on win32 seems to do this as well: it applies stdcall to the XPCOM class (interface) methods. In D (windows) it would look like so (assuming you have done away with the compilers internal detection of COM interfaces): extern(C++) interface IUnknown: { extern(Windows): int QueryInterface(nsIID* uuid, void **result); int AddRef(); int Release(); } I bet it would work fine and would be a good way to avoid the special-cased interfaces providing COM support in D. Instead we've special-cased for C++, which is, at least, a more general case. ;-) -JJR
Dec 01 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 In D (windows) it would look like so (assuming you have done away with 
 the compilers internal detection of COM interfaces):
 
 extern(C++) interface IUnknown:
 {
     extern(Windows):
         int QueryInterface(nsIID* uuid, void **result);
         int AddRef();
         int Release();
 }
 
 I bet it would work fine and would be a good way to avoid the 
 special-cased interfaces providing COM support in D.  Instead we've 
 special-cased for C++, which is, at least, a more general case. ;-)

There is one other problem. COM objects are not collected by the garbage collector because they are reference counted. Deriving from IUnknown means its a COM object which sets a flag in the ClassInfo, directing the garbage collector to not collect it. In fact, COM objects are allocated using malloc(). IUnknown.Release() uses free() to deallocate them.
Dec 02 2008
next sibling parent reply John C <johnch_atms hotmail.com> writes:
Walter Bright Wrote:

 John Reimer wrote:
 In D (windows) it would look like so (assuming you have done away with 
 the compilers internal detection of COM interfaces):
 
 extern(C++) interface IUnknown:
 {
     extern(Windows):
         int QueryInterface(nsIID* uuid, void **result);
         int AddRef();
         int Release();
 }
 
 I bet it would work fine and would be a good way to avoid the 
 special-cased interfaces providing COM support in D.  Instead we've 
 special-cased for C++, which is, at least, a more general case. ;-)

There is one other problem. COM objects are not collected by the garbage collector because they are reference counted. Deriving from IUnknown means its a COM object which sets a flag in the ClassInfo, directing the garbage collector to not collect it. In fact, COM objects are allocated using malloc(). IUnknown.Release() uses free() to deallocate them.

But IUnknown.Release does no such thing. If you're talking about the implementation in std.c.windows.com.ComObject, then all it does is decrement the reference count. It has a comment saying "let the GC reap it" - which is incorrect, since the GC doesn't collect COM objects (as you say above). So anyone deriving from ComObject is leaking memory. John C.
Dec 02 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
John C wrote:
 But IUnknown.Release does no such thing. If you're talking about the
 implementation in std.c.windows.com.ComObject, then all it does is
 decrement the reference count. It has a comment saying "let the GC
 reap it" - which is incorrect, since the GC doesn't collect COM
 objects (as you say above). So anyone deriving from ComObject is
 leaking memory.

There does appear to be a bug there, because the allocator allocates it with malloc().
Dec 02 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 John Reimer wrote:
 
 In D (windows) it would look like so (assuming you have done away
 with the compilers internal detection of COM interfaces):
 
 extern(C++) interface IUnknown:
 {
 extern(Windows):
 int QueryInterface(nsIID* uuid, void **result);
 int AddRef();
 int Release();
 }
 I bet it would work fine and would be a good way to avoid the
 special-cased interfaces providing COM support in D.  Instead we've
 special-cased for C++, which is, at least, a more general case. ;-)
 

garbage collector because they are reference counted. Deriving from IUnknown means its a COM object which sets a flag in the ClassInfo, directing the garbage collector to not collect it. In fact, COM objects are allocated using malloc(). IUnknown.Release() uses free() to deallocate them.

Okay, that is an important detail for me to know. But I assumed that a C++ interface must not be allocated in D either. In must acquire a pointer from an external factory that handles the allocation outside of the gc range (C++ code must allocate/delete it's own objects). This seems to me to be a somewhat equivalent process as for a COM object. Is there a ClassInfo flag indicating no-gc-collection for extern(C++) interfaces too? -JJR
Dec 02 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 Okay, that is an important detail for me to know.  But I assumed that a 
 C++ interface must not be allocated in D either.  In must acquire a 
 pointer from an external factory that handles the allocation outside of 
 the gc range (C++ code must allocate/delete it's own objects).
 
 This seems to me to be a somewhat equivalent process as for a COM object.
 
 Is there a ClassInfo flag indicating no-gc-collection for extern(C++) 
 interfaces too?

No. The COM object is special because part of its interface is to do its own memory management, that isn't true in general for C++ interfaces.
Dec 02 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 02 Dec 2008 22:32:33 -0800, Walter Bright wrote:

 John Reimer wrote:
 Is there a ClassInfo flag indicating no-gc-collection for extern(C++) 
 interfaces too?

No. The COM object is special because part of its interface is to do its own memory management, that isn't true in general for C++ interfaces.

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; } Here, there are no references left in D code to the created interface object and GC is free to collect it even though it's still being used from within C++ code. I'll have to manage a list of created interface object simply to keep them alive, getting another multi-threading headache, or add them as GC roots. I think it's better to assume manual memory management for extern(C++) objects.
Dec 04 2008
parent reply Jason House <jason.james.house gmail.com> writes:
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.
Dec 06 2008
parent reply John Reimer <terminal.node gmail.com> writes:
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;
 }


(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): extern(C++) Foo create(); // in C++ code this is something like Foo* create() { return new Foo; } extern(C++) void destroy(Foo F); // also in C++ code since the same should destroy it In the D code, the factory function enforces the stricture that the C++ code is responsible for it's own object creation and destruction. D code should touch this. About the only thing that the D gc might monitor is the D interface reference created. Assignment to the extern(C++) interface in D like so: Foo F = create(); ensures that we have access to the C++ object. Perhaps a scope() statement may be used to call the C++ destroy method. 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. The fact that D 2.0 uses a special-case of D interface (kind of similar to COM interfaces) was primarily why I became interested in the possibility of using it as an opportunity to interface with XPCOM. But it seems XPCOM is more appropriatly implemented by taking advantage of the COM alias functionality as is. Also the extern(C++) technique is a D 2.0-only feature, so I will leave such experimentation for the such a time as DWT/XPCOM is ready to be ported to D 2.0. -JJR
Dec 06 2008
next sibling parent John Reimer <terminal.node gmail.com> writes:
 In the D code, the factory function enforces the stricture that the
 C++ code is responsible for it's own object creation and destruction.
 D code should touch this.  

Last line above meant to say: "D code should NOT touch this" as in, D code should not take any responsibility for creation/destruction of the object. -JJR
Dec 06 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
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;
 }


(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().
Dec 08 2008
parent John Reimer <terminal.node gmail.com> writes:
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;
 }


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):

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.
 

your definition of interface Foo, here is the implementation:
 extern(C++) interface Foo {
 int foo(int a, int b);
 }

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
Dec 08 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 02 Dec 2008 13:23:55 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 John Reimer wrote:
 In D (windows) it would look like so (assuming you have done away with  
 the compilers internal detection of COM interfaces):
  extern(C++) interface IUnknown:
 {
     extern(Windows):
         int QueryInterface(nsIID* uuid, void **result);
         int AddRef();
         int Release();
 }
  I bet it would work fine and would be a good way to avoid the  
 special-cased interfaces providing COM support in D.  Instead we've  
 special-cased for C++, which is, at least, a more general case. ;-)

There is one other problem. COM objects are not collected by the garbage collector because they are reference counted. Deriving from IUnknown means its a COM object which sets a flag in the ClassInfo, directing the garbage collector to not collect it. In fact, COM objects are allocated using malloc(). IUnknown.Release() uses free() to deallocate them.

Well, C++ objects shouldn't be garbage-collected either, should they?
Dec 02 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 Walter Bright wrote:
 John Reimer wrote:
 So extern(System) does not translate to extern(C)?   Does that mean 
 that all extern(System)'s in my code are defaulting to extern(D)?

 That'd be a shocker to me. :)  If that's true, it would certainly 
 change my understanding of what I thought was making my code work. :D

No, extern(System) does on linux just what it does on windows, it's just that there's no point to it on linux.

I thought the whole point of extern(System) was to provide a workaround when... version(Windows) extern(Windows): else extern(C): ...stopped working ?!? from spec: "System is the same as Windows on Windows platforms, and C on other platforms"

I goofed, you're right.
Dec 01 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?
 

Just to make this clear, I'm banking on that the fact that extern(C++) on an interface should also remove the necessity to alias to a COM interface on linux. I am guessing that extern(C++) makes a vtable the same as COM minus the extern(Windows) decoration. If this is not exactly true, then my hypothesis won't hold. :-) -JJR
Nov 30 2008
next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello John,

 Hello Walter,
 
 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?
 

on an interface should also remove the necessity to alias to a COM interface on linux. I am guessing that extern(C++) makes a vtable the same as COM minus the extern(Windows) decoration. If this is not exactly true, then my hypothesis won't hold. :-) -JJR

One more detail: I just want to emphasize that solution to this is important primarily for the sake of compiler portability. At this point, dwt Browser code compiles fine with dmd (at this point, only with dmd), but with the hacks I've used, there are certainly no guarantees that it will ever work with other compilers. Finding a clean way to implement this is therefore fairly important, I think. And since I'd consider XPCOM/Mozilla a significant niche in software development - especially in crossplatform software development - I think this only emphasizes the necessity of getting this working nicely. :) That said, I'll try to cook up an example using dmd 2.0 to see if this will work with extern(C++). -JJR
Nov 30 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 Hello Walter,
 
 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?

Just to make this clear, I'm banking on that the fact that extern(C++) on an interface should also remove the necessity to alias to a COM interface on linux. I am guessing that extern(C++) makes a vtable the same as COM minus the extern(Windows) decoration. If this is not exactly true, then my hypothesis won't hold. :-)

Neither affects the vtable layout. They affect the calling convention (register usage, parameter order, stack cleaning, return value).
Nov 30 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 John Reimer wrote:
 
 Hello Walter,
 
 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?
 

extern(C++) on an interface should also remove the necessity to alias to a COM interface on linux. I am guessing that extern(C++) makes a vtable the same as COM minus the extern(Windows) decoration. If this is not exactly true, then my hypothesis won't hold. :-)

(register usage, parameter order, stack cleaning, return value).

Okay, I'm confused then. While I understand that the compiler uses specifically uses extern(...) to describe the calling convention, I /assumed/ that the compiler was detecting this the extern(C++) like so: extern (C++) { interface D { int bar(int i, int j, int k); } D getD(); } And converting what would normal be a D interface (with RTTI reference in first element of vtable) to a regular vtable compatible with a C++ class type? How is the vtable made C++ compatible? -JJR
Nov 30 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 Okay, I'm confused then.  While I understand that the compiler uses 
 specifically uses extern(...) to describe the calling convention, I 
 /assumed/ that the compiler was detecting this the extern(C++) like so:

I think you're right, I'd forgotten.
Nov 30 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 Hello Walter,
 
 John Reimer wrote:

 Hello Walter,

 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?

extern(C++) on an interface should also remove the necessity to alias to a COM interface on linux. I am guessing that extern(C++) makes a vtable the same as COM minus the extern(Windows) decoration. If this is not exactly true, then my hypothesis won't hold. :-)

(register usage, parameter order, stack cleaning, return value).

Okay, I'm confused then. While I understand that the compiler uses specifically uses extern(...) to describe the calling convention, I /assumed/ that the compiler was detecting this the extern(C++) like so: extern (C++) { interface D { int bar(int i, int j, int k); } D getD(); } And converting what would normal be a D interface (with RTTI reference in first element of vtable) to a regular vtable compatible with a C++ class type? How is the vtable made C++ compatible?

You're right, I was wrong. It looks like all I need to do is change the default linkage inside IUnknown from Windows to System, as System is implemented as Windows under windows, and C under linux.
Dec 01 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 John Reimer wrote:
 
 Hello Walter,
 
 John Reimer wrote:
 
 Hello Walter,
 
 So are you saying that XPCOM will work on Linux with D if only the
 extern(Windows) was actually extern(C++) ?
 

extern(C++) on an interface should also remove the necessity to alias to a COM interface on linux. I am guessing that extern(C++) makes a vtable the same as COM minus the extern(Windows) decoration. If this is not exactly true, then my hypothesis won't hold. :-)

convention (register usage, parameter order, stack cleaning, return value).

specifically uses extern(...) to describe the calling convention, I /assumed/ that the compiler was detecting this the extern(C++) like so: extern (C++) { interface D { int bar(int i, int j, int k); } D getD(); } And converting what would normal be a D interface (with RTTI reference in first element of vtable) to a regular vtable compatible with a C++ class type? How is the vtable made C++ compatible?

It looks like all I need to do is change the default linkage inside IUnknown from Windows to System, as System is implemented as Windows under windows, and C under linux.

Yes, that would be the fastest way to fix it. Thanks. -JJR
Dec 01 2008