http://d.puremagic.com/issues/show_bug.cgi?id=4092
--- Comment #4 from Rainer Schuetze <r.sagita...@gmx.de> 2011-02-08 00:41:49
PST ---
The problem with allocating COM objects from the C-heap is that they cannot be
free'd inside Release() due to possible invariants being called after that.
Here's the implementation of Release in std.c.windows.com:
ULONG Release()
{
LONG lRef = InterlockedDecrement(&count);
if (lRef == 0)
{
// free object
// If we delete this object, then the postinvariant called upon
// return from Release() will fail.
// Just let the GC reap it.
//delete this;
return 0;
}
return cast(ULONG)lRef;
}
The comment even implies that the memory should be taken from the GC.
Also, any object that has references into other memory blocks needs to add
itself as a root to the GC, which can be very easily forgotten (e.g. if the
references are just strings).
As reported lately, the juno project
(http://www.dsource.org/projects/juno/wiki, probably the largest project trying
to embrace COM), works similar as proposed here. (
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=128956
)
Agreed, changing this might break some code, but probably most applications
creating COM objects have overloaded new anyway.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
