digitalmars.D.bugs - [Issue 3732] New: Not all COM interfaces inherit from IUnknown.
- d-bugmail puremagic.com (29/29) Jan 20 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3732
- d-bugmail puremagic.com (10/10) Jan 21 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3732
- d-bugmail puremagic.com (10/10) Jan 22 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3732
- d-bugmail puremagic.com (13/13) Jun 12 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3732
http://d.puremagic.com/issues/show_bug.cgi?id=3732 Summary: Not all COM interfaces inherit from IUnknown. Product: D Version: 2.037 Platform: x86 OS/Version: Windows Status: NEW Severity: minor Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: burton-radons shaw.ca PST --- Well this is rude. It turns out some COM interfaces - I specifically know of ID3D10Include (http://msdn.microsoft.com/en-us/library/ee419311%28VS.85%29.aspx) - do not inherit from IUnknown. Since inheritance from IUnknown is how DMD applies its magic, it means that such interfaces cannot be implemented directly from D. It would seem preferable to have a "pragma (COM)" or "pragma (com)" attribute to apply to an interface to cause it and its descendants to be understood to be COM participants than to inherit from IUnknown, which seems an outdated commonality, unfortunately. The justification from Microsoft's side seems to be that ID3D10Include objects should be lightweight, so removing IUnknown allows them to be stack objects since it's impossible for anyone to retain a living reference to them after returning. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3732 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 15:42:45 PST --- Does the interface not have aquire, release, and queryinterface methods? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 21 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3732 PST --- Nope. I've since found that this is also common to most of the interfaces used in the reflection API for DirectX 10 and 11, which you're not supposed to implement. I think the intent is the same, just the opposite direction - they're trying to serve objects whose lifetimes are completely dependent on the root object. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 22 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3732 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |yebblies gmail.com Resolution| |INVALID The correct solution would be to use extern(C++) interfaces. The bug is really in microsoft calling something a com class which isn't. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 12 2011