http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #10 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-27 08:56:35 PDT ---
(In reply to comment #9)
> https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d#L28

Nice, this will be useful for me. Thanks.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #11 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-27 09:00:44 PDT ---
> (In reply to comment #9) https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d#L28

Hmm, you seem to have this prototype in that file:

extern(C) void* gc_malloc(size_t sz, uint ba = 0, const TypeInfo ti=null);

However there is no such function which takes these parameters in druntime (in 2.064 anyway), the function takes 2 parameters, not 3. I suspect this links fine but would probably do something nasty like corrupt the stack.

I suspect you've prototyped it to avoid an import into core.memory?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #12 from Rainer Schuetze <r.sagitario@gmx.de> 2013-09-27 13:31:42 PDT ---
(In reply to comment #11)
> Hmm, you seem to have this prototype in that file:
> 
> extern(C) void* gc_malloc(size_t sz, uint ba = 0, const TypeInfo ti=null);


This is the prototype for the precise GC, but it should do no harm elsewhere because the additional parameter in an extern(C) function is ignored by the called function and is removed from the stack by the callee.

If you want to use the methods with the current GC and the respective imports, just leave out the third argument.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #13 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-27 13:33:33 PDT ---
(In reply to comment #12)
> This is the prototype for the precise GC, but it should do no harm elsewhere because the additional parameter in an extern(C) function is ignored by the called function and is removed from the stack by the callee.

Ah ok, thanks.

Just one other thing, it's often mentioned that the reference count of a COM object should always start at 1, but your ComObject class starts with 0. Maybe this isn't an issue because it's incremented in the QueryInterface() call?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #14 from Rainer Schuetze <r.sagitario@gmx.de> 2013-09-27 13:52:28 PDT ---
The reference count might be slightly different than what's used in a language without GC, but I think starting at 0 is appropriate here. The object pointer can be used by the D program without any reference counting, it is only used to count (external) references to COM interfaces to avoid premature collection by keeping a root to the object in the GC.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #15 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-28 04:20:28 PDT ---
(In reply to comment #9)
> The patch in druntime would make this obsolete.

This issue really does need to be resolved, e.g. the newCom function can't be used for COM classes with private constructors.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------