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