On 12.09.19 05:02, Vicram Rajagopalan via Boost wrote:
1. Would you use something like this if it were available?
I would not use it because I do not use Boost Program Options, and I do not expect a straight port to solve the problems I have with Boost Program Options. These problems are: 1. Unicode support is based on wchar_t instead of utf8. wchar_t has an implementation-defined width which makes it unsuitable for portable Unicode code. The correct way to handle Unicode in general is to use narrow strings encoded as utf-8. The correct way to handle Unicode on Unix systems is to accept narrow strings and to assume that they are in utf-8, regardless of locale. The correct way to handle Unicode on Windows is to accept wide strings and convert them to utf-8 immediately when received. I could, of course, perform my own conversion to utf-8 and pass the result to Boost Program Options, but that approach seems brittle given that Boost Program Options assumes that 8-bit strings are in the "local 8-bit encoding". 2. I have found that code that uses Boost Program Options is neither easier to write nor more maintainable than code which parses command line options manually. -- Rainer Deyke (rainerd@eldwood.com)