Boost logo

Boost Users :

Subject: Re: [Boost-users] program_options: one-of-set option format
From: Daryle Walker (darylew_at_[hidden])
Date: 2008-10-29 16:24:39

On Oct 12, 2008, at 3:15 AM, Vladimir Prus wrote:

> 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.

Does Program_Options support subcommands, like the traditional CVS
and SVN command-line clients do? Subcommand support requires some
sort of mutual exclusiveness, so code could be reused for the
poster's problem.

Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at