Re: [boost] Silly Boost.Locale default narrow string encodinginWindows

Subject: Re: [boost] Silly Boost.Locale default narrow string encodinginWindows
From: bugpower (bugpwr_at_[hidden])
Date: 2011-10-31 13:18:01

Alf, All,

What replies seem to be missing here is that what you call the "least
surprise" behavior of the code with argument of main(), is simply incorrect
from the software engineering point of view. Let me explain:

>   3. the most natural sufficiently general native encoding, 1 or 2
>      depending on the platform that the source is being built for.

Now, when accepting filename from the user's command line on Windows, it is
simply not possible to use narrow-string version of main(). Your code cannot
enforce your user to limit his input to characters representable in the
current ANSI codepage. If the command line parameter is a filename as in the
example you suggested, you cannot tell them "never double click on some
files" (if a program used in a file association). Supporting is always
better than white-listing, so the only acceptable way of using command line
parameter which is a filename on windows is with UTF-16 version - _tmain(). 

Then, proceed as Artyom explained. The surprise is then justified - it
prevented a hard-to-spot bug. My preference on Windows though would be
different (and not due to religious reasons) - convert all API-returned
strings to UTF-8 as soon as possible and forget about encoding issues for
good. See
http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful

--
View this message in context: http://boost.2283326.n4.nabble.com/Silly-Boost-Locale-default-narrow-string-encoding-in-Windows-tp3945105p3956482.html
Sent from the Boost - Dev mailing list archive at Nabble.com.