Strange fallout changing modules

Sean Cavanaugh WorksOnMyMachine at gmail.com
Fri Aug 10 23:50:25 PDT 2012


	While working on project using COM I noticed that the win32 bindings 
project declares its own version of IUnknown and all the classes in the 
project derive from this.

	So I set out to see the feasibility of modifying the win32 module to 
use std.c.windows.com.IUnknown.  This was a bit of work as there are a 
duplicate redefinitions in the project for methods like CoInitialize, 
structs like GUID, aliases like IID etc, but fairly simple.

	In the end I had a handful (approximately 10) files that needed fixing. 
The fix was simple: add 'private import std.c.windows.com' to the top of 
each file generating symbol collisions, and replace the duplicate 
symbols the compiler was complaining about with an alias to the 
equivalent object in std.c.windows.com.

	The code compiles great, but now the weird thing:  Before this change I 
had to compile 13 .d files out of the win32 module.  After the change I 
had to add 37 others, and also suffer numerous import lib not found 
warnings because I am effectively compiling dead code that pragma 
includes lib's I don't need.

	Can anyone explain this behavioral change?


	Also, the more I work on this the more I wonder if D should also not 
allow any other IUnknown interfaces to be declared, that are not an 
alias to std.c.windows.com (or wherever each platform's canonical 
version lives).  It makes it impossible to easily write a static assert 
in interface containers that emulate ATL's CComPtr: i.e.  i have to write

     static assert(is(T : std.c.windows.com.IUnknown) || is(T : 
win32.unknwn.IUnknown));

instead of:

static assert(is(T : std.c.windows.com.IUnknown));

and also hope nobody adds another one somewhere else.


More information about the Digitalmars-d mailing list