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

Subject: Re: [boost] program_options: Support for open-end options
From: ST (smntov_at_[hidden])
Date: 2012-12-30 07:07:25

> Hi,
> 
> just a couple of points:
> 
> - It is generally advisable to CC me personally. I do check this list,
> but not as often as before
> - I'll be on public holiday starting really soon and returning on Jan
> 9, so expect some delay :-(

To Volodya:
Is there a chance you express your opinion on this issue before 31.12
starts? :)

Thank you

On Thu, 2012-12-27 at 10:28 -0500, Rob Stewart wrote:
> On Dec 26, 2012, at 12:56 PM, ST <smntov_at_[hidden]> wrote:
> 
> > 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 .
> 
> I think that's really odd, though I understand that you want something to allow a great number of options without defining them ahead of time.

Why is it odd? I find it pretty intuitive/flexible and seems to be not
that hard to implement.

> My first thought was a command line delimiter to introduce a list of such options:
> 
> ... --foo 1=23 2=45 ... N=465

My way this would be: --foo_1 23 --foo_2 45 ... --foo_N 465

> 
> You'd specify "foo" as the delimiter and PO would then parse the remaining values into pairs to populate a map. Since the set of name/value pairs is open ended, they would always go last on the command line.

With my aproach there is no need for this limitation and you can have as
many open-ended options as you like.

>  Of course, you could also specify a delimiter to signal the end of the pairs. (If you want validation that the option names match a pattern, you can add that, too.)
> 
> To avoid the name/value pairs, the following could be used to populate a vector:
> 
> ... --foo 23 45 ... 465

Sometimes one wants to use strings to distinguish between such
open-ended options and not numbers(indices of a vector in that case),
for example:

--os_linux 435 --os_solaris 234 --os_mac 123

In my specific case I need to have the ability to "see" options that
were ommitied (on purpose), like:

# visible points and their current coordinates
[second_123]
point_1 = 12 45 1
point_5 = 65 23 23

[second_124]
point_1 = 12 47 3
point_4 = 212 565 12
point_7 = 122 453 157

So map is the right option here.

Thank you,
Simone