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.