On 3/3/11 3:30 PM, Graham St Jack wrote:
My first instinct would be to use non-templated functions that take const
char[].
Please don't ever restrict encodings like that. As much as possible,
libraries should seek to be encoding agnostic (though I'm all for
const-qualifying parameters). This is one area where I feel the
standard library severely lacks at present.
As a Windows developer, I prefer to use wchar strings by default and use
only the W versions of the Windows API functions, because the A versions
severely limit functionality. Only the W versions have full support for
Unicode; the A versions are entirely dependent on the current (8-bit)
code page. This means no support for UNC paths or paths longer than 260
characters, and also means that international characters commonly end up
completely garbled. Good practice in Windows is to consider the A
versions deprecated and avoid them like the plague.
References:
http://msdn.microsoft.com/en-us/library/dd317752%28v=VS.85%29.aspx
http://blogs.msdn.com/b/michkap/archive/2006/10/24/867880.aspx
http://blogs.msdn.com/b/michkap/archive/2006/08/22/707665.aspx
http://blogs.msdn.com/b/michkap/archive/2007/05/07/2464778.aspx
When I first started looking at D, I compiled the win32 example on the D
web page. I noticed it used MessageBoxA, so I changed that to
MessageBoxW. That generated an error, because nobody had bothered to
add a MessageBoxW declaration. That was the very last time I used
std.c.windows.
