Let's schedule WinAPI ASCII functions for deprecation!

Denis Shelomovskij verylonglogin.reg at gmail.com
Thu May 24 04:40:36 PDT 2012


23.05.2012 0:41, Walter Bright написал:
> Secondly, as a matter of principle, we are not going to fix, improve,
> refactor, or re-engineer the Windows API, nor any other operating system
> API, nor the C Standard Library, no matter how tempting that may be. The
> job of the D interface modules is to simply provide an interface to
> them, as thin and direct as possible, without editorial comment. The
> user can decide what to use or not use from it.
>

The key point is what does it mean "interface"?

An ability to load DLL and get symbols from it is enough to use every 
function. Is it an interface? You say "no".

It's common in C/C++ to use WinAPI functions without A/W postfixes 
because preprocessor defines it according to your preferences. Is it an 
interface? You say "no".

Functions like C's memmove are deprecated in VC headers on Windows 
because they are unsafe. Is it an interface? You say "no".

WinAPI functions are more than just C definitions, they have IDL to 
allow user to avoid pointers and exit code checking. Is it an interface? 
You say "no". There is no such macros in Windows headers even for dmc 
and there is no talks at all to generate good D wrappers for WinAPI 
functions based on its IDL.

*A functions are in WinAPI headers obviously for backward compatibility 
only. Are they definitions an interface? You say "yes".


And I completely disagree with the last 2 points.

I just want to show that this "principle" isn't as well-shaped as it can 
look at first sight.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij


More information about the Digitalmars-d mailing list