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:
> 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
> 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!
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk