I had some questions about using program_options with wstrings. I'm a bit confused after reading the documentation: http://www.boost.org/doc/libs/1_40_0/doc/html/program_options/howto.html#id1... http://www.boost.org/doc/libs/1_40_0/doc/html/program_options/design.html#pr... Excerpt: """ - Each parser should accept either char* or wchar_t*, correctly split the input into option names and option values and return the data. - For each option, it should be possible to specify whether the conversion from string to value uses ascii or Unicode. - The library guarantees that (1) ascii input is passed to an ascii value without change, (2) Unicode input is passed to a Unicode value without change, and (3) ascii input passed to a Unicode value, and Unicode input passed to an ascii value will be converted using a codecvt facet (which may be specified by the user). """ Bullet 1 tells me the system takes both char* and wchar_t*. Bullet 2 tells me that each option can request the string it's handed to be first coerced as either a char* or wchar_t*. This is the only char/wchar_t conversion that happens in the system (codecvt). Why, then, can't I say value<wstring> (besides wvalue<wstring>)? And why do I need to specify command_line_parser vs. wcommand_line_parser? The complexity stems from the fact that there seem to be three sets of variables in the code: - value vs. wvalue - [w]value<string> vs. [w]value<wstring> - command_line_parser vs. wcommand_line_parser I find it unclear what the consequences are of setting each of these one way vs. the other. Any explanations? Related: I ran into this bug: http://lists.boost.org/boost-users/2008/02/34016.php https://svn.boost.org/trac/boost/ticket/1645 Why does this happen? -- Yang Zhang http://www.mit.edu/~y_z/