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-consi... -- View this message in context: http://boost.2283326.n4.nabble.com/Silly-Boost-Locale-default-narrow-string-... Sent from the Boost - Dev mailing list archive at Nabble.com.