Hi, 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 locale. I understand, that stl support unicode for unicode is not the best, but there are facilities, that can provide required functionality if properly extended/configured. 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. Regards, Pavol 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
http://zigzag.cs.msu.su:7813/program_options/html/program_options.design.htm... or http://zigzag.cs.msu.su/~ghost/program_options/html/program_options.design.h...
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: http://lists.boost.org/mailman/listinfo.cgi/boost