Re: [program_options] Proposal: self-contained, header-only port of Boost Program Options library

From: Rainer Deyke (rainerd_at_[hidden])
Date: 2019-09-12 07:57:27

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_at_[hidden])