A typical COM server would create a new object (derived from IUnknown), return it to the caller (potentially written in other languages). Because the object pointer now resides outside of D's managed heap, does that mean the object will be destroyed when the GC runs? A normal COM object written in C++ relies on reference counting to manage its life cycle but in D the ref counting seems not serving any purpose. The AddRef()/Release() of std.c.windows.com.ComObject maintains a ref count, but doesn't really use it for any thing. There's a comment in Release() says "let the GC reap it", but how does the GC know the object is okay to destroy?

On 6/11/2013 10:38 PM, finalpatch wrote:
> A typical COM server would create a new object (derived from IUnknown),
> return it to the caller (potentially written in other languages).
> Because the object pointer now resides outside of D's managed heap, does
> that mean the object will be destroyed when the GC runs? A normal COM
> object written in C++ relies on reference counting to manage its life
> cycle but in D the ref counting seems not serving any purpose. The
> AddRef()/Release() of std.c.windows.com.ComObject maintains a ref count,
> but doesn't really use it for any thing. There's a comment in Release()
> says "let the GC reap it", but how does the GC know the object is okay
> to destroy?

COM is by definition ref counted.  In D you generally need to store a COM pointer in a struct and maintain the refcount with that struct (increment on copy, decrement in destructor, etc).  Its not too hard, as 'alias this' usage can wrap the pointer's methods easily enough.

Hi Sean,

Thanks for your reply. I have no problem with client side COM programming in D. What I'm asking is if I write a COM object in D (in this case the D code is a COM server), then it looks like I have to store a reference to that COM object in some globally reachable place (eg. add it to a global array, so that it won't be destroyed by the GC while the C++/.NET client is still using it), and then manually remove that reference when the object's ref count drops to zero for the GC to collect it.

This feels even more cumbersome than in C++ because in C++ we can simply delete this in the Release() method, there's no need to store a reference in a global place.

Sean Cavanaugh <WorksOnMyMachine@gmail.com> writes:
> COM is by definition ref counted.  In D you generally need to store a COM pointer in a struct and maintain the refcount with that struct (increment on copy, decrement in destructor, etc).  Its not too hard, as 'alias this' usage can wrap the pointer's methods easily enough.
>
>

-- 
finalpatch

On Wednesday, 12 June 2013 at 14:41:05 UTC, finalpatch wrote:

>
> This feels even more cumbersome than in C++ because in C++ we can simply
> delete this in the Release() method, there's no need to store a
> reference in a global place.
>


Juno does this by allocating the object on the non-gc heap, adding it as a GC root, and then deleting it when the refcount reaches 0.
It works ok, though I think the current implementation has some issues.

"Richard Webb" <webby@beardmouse.org.uk> writes:

> On Wednesday, 12 June 2013 at 14:41:05 UTC, finalpatch wrote:
>
>>
>> This feels even more cumbersome than in C++ because in C++ we can
>> simply
>> delete this in the Release() method, there's no need to store a
>> reference in a global place.
>>
>
>
> Juno does this by allocating the object on the non-gc heap, adding it
> as a GC root, and then deleting it when the refcount reaches 0.
> It works ok, though I think the current implementation has some
> issues.

I was reading the CHello sample that ships with DMD. I don't see anything that can prevent the GC from killing a running object, this makes me wonder whether it is actually a correct sample.

-- 
finalpatch

I was referring to the COM server support stuff in the Juno library, which allocates COM objects outside the GC heap so the GC will never collect them.

See https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/juno/com/core.d#L3147 for an example.