--- Comment #4 from Rainer Schuetze <r.sagita...@gmx.de> 2011-02-08 00:41:49
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:
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.
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. (
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: -------