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.
"Richard Webb" 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
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,
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 gl
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 t
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
