Re: [boost] program_options: Support for open-end options

Subject: Re: [boost] program_options: Support for open-end options
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2012-12-27 09:35:42

On Thu, Dec 27, 2012 at 8:43 AM, Joshua Boyce <raptorfactor_at_[hidden]
> wrote:

> On Thu, Dec 27, 2012 at 4:56 AM, ST <smntov_at_[hidden]> wrote:
>
> > Hi,
> >
> > It would be great to implement support for open-end options, something
> > like that:
> >
> > item_1 = 23
> > item_2 = 45
> > ...
> > item_N = 465
> >
> > The idea is to to be able to provide following input:
> >
> > configOptions.add_options()
> >         ("item_", value<int>(), "items");
> >
> > now if add_options() sees a key that ends with a "_" it accepts all
> > options with keys that start with item_, no matter what comes after it,
> > and treat all of them as int . Nesting should also be possible - like
> > this: "item_.subitem_.subsubitem_" (item_3.subitem_FOO.subsubitem_34
> > should be a valid option key).
> > I can try to implement it, however only if it will have a chance to be
> > merged into the boost library. Whom should I contact regarding this?
> >
> > Thank you,
> > Simone
> >
> >
> >
> I have a definite use case for the type of open-ended options you're
> proposing here.
>
> It seems you want to get into contact with Vladimir Prus. He's an active
> member of the mailing list, so you should have no issues getting a
> response.

I'll echo that.  I have had a need for this support (although I worked
around it).

Sometimes, it isn't good enough to do something like:

variable_name = itemA|itemB|itemC|itemD

maybe because 'itemA' is actually a string of characters over 80 characters
long or requires special characters that make it non-obvious how to
separate the items in the list.

Although I'd probably prefer a signature that used a sort of tag instead of
relying upon the appending '_' character to trigger the list, and I'd
prefer to use a regular expression instead of relying upon the ending.  For
example:

namespace po = boost::program_options;
configOptions.add_options()
     ( "item_.*", po::value<int>(), "items", po::regex );

That would let you use some fairly interesting variable names while
ensuring they have the right type.  You shouldn't be able to use the
following signature, though:

configOptions.add_options()
     ( "item_.*", po::value<int>( &my_var ), "items", po::regex );

And I should think it would get very odd to try to put the variables in a
single container for those cases where someone skipped a number or
something, e.g.:

configOptions.add_options()
     ( "item_.*", po::value< std::vector< int > >( &my_var ), "items",
po::regex );

- Trey