WinAPI for druntime and OpenGL for deimos.

Vladimir Panteleev vladimir at thecybershadow.net
Fri Nov 23 17:06:16 PST 2012


On Friday, 23 November 2012 at 21:21:49 UTC, Walter Bright wrote:
> On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
>> There might be some incompatibilities, for example due to how 
>> the HANDLE type is
>> declared. In C, you can use either 0 or NULL as a parameter to 
>> a function
>> accepting an integer or pointer. In D, you cannot. IIRC, some 
>> types were
>> declared differently in Druntime's modules and in the win32 
>> bindings.
>>
>> If breaking code were not an issue, the best solution would be 
>> to make HANDLE a
>> unique, opaque type (like a struct wrapping an intptr_t or 
>> void*) - which is
>> exactly how it should be treated. It would need to support 
>> assignment/creation
>> from "null" though.
>
> This is why I don't approve of attempts to "fix" Windows APIs. 
> It winds up being incompatible here and there, and breaks 
> things.

I don't think I follow the logic of this argument.

Let's say that Phobos had a templated function that, by mistake, 
accepted arguments at compile-time the types of which made no 
sense for said function.

Should the bug be fixed, even though it would break compilation 
of code most of which used incorrect invocations of that 
function? Or should the bug be kept, because fixing it would 
break compilation of code that relied on the bug?

If the analogy is invalid, what is the exact problem with 
changing HANDLE's type? How much real correct code would break? 
How does the inconvenience of forcing users to add a few casts 
compare to making it easy to accidentally mix HANDLEs with other 
opaque types and pointers in general?

I should point out that some functions (e.g. GlobalLock, IIRC) 
take a value, and return the exact same value, but with another 
type. This forces the user to use the function as a "gate", lest 
they erroneously use the value directly. Using weak typing makes 
it too easy to e.g. assign an unlocked memory region to a pointer.


More information about the Digitalmars-d mailing list