On 7/9/2011 2:42 PM, Andrej Mitrovic wrote:
Btw, the issue with those conflicting functions could be resolved by
careful uses of selective imports:
import win32.wingdi;
// This overwrites win32\wingdi : wglMakeCurrent, wglDeleteContext,
wglCreateContext;
import derelict.opengl.wgl : wglMakeCurrent, wglDeleteContext, wglCreateContext;
// This overwrites win32.basetsd or wherever HGLRC is
import derelict.util.wintypes : HGLRC;
But again, that doesn't scale as it gets tedious to have to do this in
every module..
The Win32 Bindings project on dsource.org project is far more complete
(even if it is missing some of Vista and a ton of Win7 functions and
enumerations). These apparently are a port of the mingw headers, but I
can't help but wonder if it would be possible to split the different
with the mingw developers and have the bindings live in a language
neutral database with a code generator for C/C++ headers and D
'headers'. I would also expect this to be of interest to Mono to
generate a complete and correct set of PInvoke bindings as well, and any
other language that wants be able to talk native to Win32.
The other major weak leak I've run across are usages of COM and
IUnknown. They are defined in a few places as well which is problematic
if you are trying to write COM interfaces that are provided by C/C++
dlls ( in my case, D3D11 bindings ).
import std.c.windows.com;
import win32.unknwn;
and a D template version of CComPtr from atl has to do two checks to see
if it is a valid IUnknown object:
struct ComPtr(T)
{
public:
static assert(is(T : std.c.windows.com.IUnknown) || is(T :
win32.unknwn.IUnknown));
T p;
alias p this;
...
}
This is a pretty huge problem since its a giant violation of DRY (Don't
Repeat Yourself). There should only be one way of doing some things.
