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 hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net