On Thursday 03 March 2011 18:04:11 Bekenn wrote: > 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.
It's not a bad thing for functions to be templatized on string type. However, I would point out that it's fairly common practice to just use string everywhere except where you need a string to be a random-access range - in which case you used dstring - or where you need to pass a string to a Windows system function, in which case you convert it to a wstring or wchar[]. The need to use wstring when using Phobos is practically non-existent. Now, if you're frequently calling Windows system functions directly, then wstring and wchar[] would be used far more frequently, but don't expect Phobos to be using wstring much. It's likely that more of Phobos will become string-type-agnostic and templatize on string type, but there may be functions which aren't simply due to the increased complexity or because no one gets around to it with everything else that needs doing. The normal string type to use is string, so that's generally what is designed for. > 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. If there are key functions like that that you expect to be druntime (in this case, it would be core.sys.windows.windows - I believe that std.c is deprecated, or at least it's not intended to be used anymore; OS-specific functions like that go in core), then open up enhancement requests for them, or they're unlikely to be added. I don't believe that anyone is going through the entirety of the Windows API (or the Posix API for that matter) and adding all those functions to druntime. They generally get added as required by Phobos or other stuff in druntime or because someone requests it. Not to mention, you can always use github to make the appropriate changes to druntime and create pull request. That would likely speed up such improvements. - Jonathan M Davis