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 optional.) 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. -------------------------------- So, - 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