Re: [Boost-users] program_options: one-of-set option format

Subject: Re: [Boost-users] program_options: one-of-set option format
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-10-12 03:15:17

Ivan Godard wrote:

> The boost::program_options library appears to lack the capability for
> one-of-set options, i.e. one of -a, -b, or -c, but not more than one,
> returned as an enumeration value in a common result for all the options.
> 
> Currently I have a function:
>     template<typename T>
>   options_description&   oneOf(options_description& od,
> std::vector<std::string>& names, T& t);
> which adds options for all the names to "od", with notifiers that update
> "t" with the "T" enumeration value corresponding to the particular
> option that the parser finds present using the ordinal position in
> "names" as a value. However, this is somewhat unsatisfying because
> detected errors (missing or too many choices) don't feed into the
> program_options reporting system. It also does not fit with the rather
> nice syntax used by the program_options library for option declarations.
> 
> I also looked at using an external parser as supported by
> program_options, but this seems low-level overkill - you get a raw
> string to parse, but none of the nice facilities for abbreviation, long
> or short forms, etc. are usable.
> 
> Lastly, I considered adding the capability as a native feature of
> program_options, but while the library is reasonably clean it doesn't
> seem to be designed to support any inter-option linkages as required for
> reporting the result and verifying that only one of the set was present.
> 
> So the question for this list: am I reinventing the wheel here and this
> oneOf capability already exists somewhere? If not, is there a better
> approach than my present purely extra-library solution?

I think the ideal approach would be to introduce new kind of value_semantics,
say, enumerated_typed_value, so the definition might be:

        desc.add_options()
                ("whatever", enum_value("a", a)("b", b), "whatever desc)
                ;

The xparse method of enumerated_typed_value would check that no value is set yet. The
problems here are that:

- xparse presently accepts only the values specified for the option, so it has no
way to tell -a from -b
- the command line parser assumes that one element of options_description results 
in one short option and one long option to be recognized, not several options,
so some refactoring will be necessary

I think the best way would be to introduce 'alias' mechanism, where -a would map
to --whatever=a, and make enumerated_typed_value make use of this mechanism. I don't
have any immediate plans to do that myself.

HTH,
Volodya