| One of the primary reasons that I (and others) avoid Boost.ProgramOptions is | that it doesn't 'natively' support wide strings (wide strings are simply | static_cast to narrow strings with no regard to localization or | internationalization). How does this library compare in that respect? This library was developed with taking an account of variable string types. Here is explanation how it is dealt with wide strings below. The class interpreter<CharType, .. > has invoke() function template. Executing the function interpreter<CharType,..>::invoke(option_name, args_iterator_begin, args_iterator_end) cause to calling appropriate handler like below option_handler ( type_cast <first_argument_type> (* (args_iterator_begin++)) , type_cast <second_argument_type> (* (args_iterator_begin++)) ... ); With this you can be sure that during intervening calls, the data will not be changed. Also in the class there is a template function "visit". By passing your 'visitor' into the function you can get information about all registered options, their alternative names and description. Display the information based on internationalization settings. One more moment that may be will have to reconsider it is parser which is present in library. I have tested it to wstring, however, it can not be working in some situations. But in any case, you have the ability use your own parser. | How does it compare to program_options in term of features, test and new | Enabled use cases? To the features can be attributed automatically detecting parameters of an option(on the basis of the signature handler). That allows us to develop more reliable code. Auto-tests of multiple base classes are available. Thank you very much for your interest. Regards, Alexey P.S. please give my apologies for long reply due to my poor English. -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-command-line-int... Sent from the Boost - Dev mailing list archive at Nabble.com.