Boost logo

Boost :

Subject: [boost] Feature suggestions for Boost's program_options
From: Eyal Rozenberg (eyalroz_at_[hidden])
Date: 2016-08-07 12:58:03

Greetings Boost developers,

[ Disclaimer:
I'm new to this list - I joined by Vladimir Prus' suggestion that I
raise my feature ideas here on the list. I've read the posting
guidelines, and I haven't seen any discussion of program_options (at
least not by Vladimir himself) for at least a year back in the list
archives, so I think my post is legit. ]

I've been using Boost's program_options library for several months now.
It mostly does the job (that's a compliment...) - but there are some
features whose lack is really bugging me. For some of them (especially
Feature Idea 1) I actually work around by taking some options as
unparsed remainders, sticking them in a string->string map and parsing
them myself.

Without further ado, and in decreasing order of importance to me:

Feature Idea 1:
Support specifying multiple alternative long option names, using
comma-separation. Right now we can specify, for example,
"include-path,I" - one short form, one long form. Why not allow
specifying "include-path,include-dir,headers-path,I" ? Only the first
long option name would be printed as part of the usage information, to
not complicate things overmuch, and merely tolerate alternative phrasing.

Feature Idea 2:
Have a (new?) parser which supports taking "semi-parsed command-line
options" as input: A map from string keys to string values, or to
optional<string> values to represent options without an argument as
well. This is actually very close to environment parsing, except that
the environment parser gets its "map" from, well, the environment
variables. So the implementation might be simply exposing the existing
functionality with a slightly richer interface.

Feature Idea 3:
A facility for pretty-printing parsed options to an std::ostream, in
which the option description starts the line, and the option value (not
the name used for parsing) is printed after it. There is some
pretty-printing for the usage info to the console, so why not this?

(Argument against this idea: Choosing a default is a very touchy subject.
Counter-argument: ... but that's also somewhat true of printing usage
information; and nobody has to use this default, it would be entirely

Feature Idea 4:
Support three rather than just two levels of describing options: name,
for the command line; short description, for listing values (see Feature
Idea 3; long description for the usage info.

Feature Idea 5:
Create a variant of update_with which doesn't just set the option value,
but creates a link of sorts between the variable which the app would use
and the variable_map entry. With this in place, further changes to the
variable map automagically affect the app variable.


- What do you think about these suggestions, in principle?
- If you find some of them relevant, can you help estimate the necessary
development effort and possible negative implications/caveats to consider?
- Assuming a feature idea is both relevant and feasible, is it customary
to request implementation by the maintainer? Commit yourself to
implementing it vis-a-vis statement of statement of partiality to
accepting a patch? Some other practice?

Thank you for getting through the long(ish) email and for your hard work,
Eyal Rozenberg
DB architecture group
CWI Amsterdam

Boost list run by bdawes at, gregod at, cpdaniel at, john at