On Thu, Dec 27, 2012 at 8:43 AM, Joshua Boyce <raptorfactor@raptorfactor.com
wrote:
On Thu, Dec 27, 2012 at 4:56 AM, ST <smntov@gmail.com> 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