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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-09-12 08:25:04

On 2019-09-12 06:02, Vicram Rajagopalan via Boost wrote:
> I am interested in creating a header-only implementation of the Boost
> Program
> Options library that only depends on the C++ standard library. Program
> Options
> uses several other Boost libraries, so I would have to re-implement some of
> it using standard library constructs.
> 
> I have 2 questions for the community:
> 1. Would you use something like this if it were available?

No.

> 2. Do you know of any implementation details of Program Options which might
> make some part of this difficult or impossible?

Even if you require C++11, there is a considerable amount of Boost used 
in ProgramOptions:

https://pdimov.github.io/boostdep-report/develop/program_options.html

It is not impossible to reimplement all that or redesign the library to 
not require some of the components, but that would be a considerable 
amount of work.

> To be clear, I do not intend for this to be merged into Boost in any form.
> 
> Rationale:
> There is no portable command-line argument-parsing capability in the C++
> standard library. There's getopt, but that's in unistd.h which is only
> available on Unix-based systems. The only widely-used C++ command-line
> parsing
> library I am aware of is Program Options, but that requires adding a
> dependency
> on Boost to your project, which seems like overkill to me. I would like to
> be
> able to simply add a project as a submodule in my Git repo and #include it
> without even having to add anything to my build files. The goal is to ensure
> that the library is as portable and easy to include as possible, because it
> shouldn't be difficult to parse command-line options.
> 
> I appreciate any thoughts, comments, or criticisms!

Boost is almost an implicit dependency of any of my projects, I find 
myself using it extensively, so the dependency on it is not a problem. 
Adding yet another dependency might be problematic, especially given 
that there is Boost.ProgramOptions already.

I understand there probably are projects that need nothing but 
Boost.ProgramOptions, where a standalone version might be useful. 
However, I do not believe reimplementing well-known components, like 
boost::any or boost::function or type traits for example, is a good 
approach. As I said, you can mitigate some of this by raising the 
minimum C++ version you require, but I don't believe raising it to e.g. 
C++17 would ease the library adoption.

Another point is that I'm not quite happy with the API 
Boost.ProgramOptions provides. If there is a new library, I would 
probably prefer a simpler API, possibly employing C++11 features, rather 
than a straight reimplementation. The new library should offer something 
new compared to the existing solutions.