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
> Options library that only depends on the C++ standard library. Program
> 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?
> 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
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.
> 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
> library I am aware of is Program Options, but that requires adding a
> on Boost to your project, which seems like overkill to me. I would like to
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk