[Boost-users] program_options and wstrings

Subject: [Boost-users] program_options and wstrings
From: Yang Zhang (yanghatespam_at_[hidden])
Date: 2009-11-09 02:30:49

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#id1396452
http://www.boost.org/doc/libs/1_40_0/doc/html/program_options/design.html#program_options.design.unicode

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/