Subject: Re: [boost] program_options: Support for open-end options
From: ST (smntov_at_[hidden])
Date: 2012-12-27 10:07:13
On Thu, 2012-12-27 at 09:35 -0500, Joseph Van Riper wrote:
> 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.
I thought about using RegEx but came to the conclusion that it is
unnecessary - you will introduce an extra dependency and implementing it
is less easy. Using '_' gives you enough flexibility.
> You shouldn't be able to use the
> following signature, though:
>
> configOptions.add_options()
> ( "item_.*", po::value<int>( &my_var ), "items", po::regex );
what if my_var is a map?
> 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 );
BTW. I have a case where numbers intentionally can be left out. Vector
is not good but map can work.
Simone