Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2004-04-06 06:02:20


I have read your proposal. Maybe I'm missing something very serious,
but I would prefere to have a similar scheme as used by stl.

So that, there will be variants accepting char and wchar_t data types,
and all possible unicode problems will be addressed by char_traits and

I understand, that stl support unicode for unicode is not the best,
but there are facilities, that can provide required functionality if properly

I think, that there is no big reason to try to reinvent a wheel and provide
all encopasing solution in the library like program_options.
It should be enough if it will be unicode-enabled so it can be used in the
any specific scenario, provided that all necessary facilities are on place.



On Tue, Apr 06, 2004 at 11:27:44AM +0400, Vladimir Prus wrote:
> Hello,
> it seems that Unicode support is the last issue that should be addressed
> before the library can be added to CVS. Since the issue is somewhat tricky,
> I'd appreciate some comments before I start coding.
> The initial description of the approach I plan is at
> or
> So summarize the document, user would be able to pass wchar_t** to the
> parse_command_line function. If specific option needs unicode, this can be
> specified like this:
> ("email", unicode::value<Email>(), "email address")
> I believe the change will be mostly transparent and won't affect ascii usage.
> All options are very welcome!
> TIA,
> Volodya
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at