program_options - required (or min/max) number of occurences declaratively?

I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options. I know it's possible to do variables_map::count("option-name") or if I have an impossible default value bound to an option, I could check for that (default would = option absence), but it might be nice to have "requiredness" be a declared option trait, that could show up in the option description. value<int>(&myoption)->required() or something like that - obviously min/max wouldn't make sense for scalars (I have no use for min/max personally). -Jonathan p.s. I know there is a concept in the command line parser of "value required or not" - I'm talking about an *option* being required.

Jonathan Graehl wrote:
I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options.
Does "min/max" number of occurrences makes much sense? In variables_map, an option is either present, or not, it cannot be present twice.
I know it's possible to do variables_map::count("option-name") or if I have an impossible default value bound to an option, I could check for that (default would = option absence), but it might be nice to have "requiredness" be a declared option trait, that could show up in the option description.
value<int>(&myoption)->required()
That's something that was requested some time ago, but not yet there. I'll note your request (really can't implement all this right before release). I think that for now you'd have to use .count. - Volodya

Vladimir Prus wrote:
Jonathan Graehl wrote:
I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options.
Does "min/max" number of occurrences makes much sense? In variables_map, an option is either present, or not, it cannot be present twice.
Yes, it does make sense. Two examples I can think of offhand are tcpdump and nmap, both of which allow you to specify the -v flag multiple times to increase verbosity.
[snip]
Michael

Michael van der Westhuizen wrote:
Vladimir Prus wrote:
Jonathan Graehl wrote:
I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options.
Does "min/max" number of occurrences makes much sense? In variables_map, an option is either present, or not, it cannot be present twice.
Yes, it does make sense. Two examples I can think of offhand are tcpdump and nmap, both of which allow you to specify the -v flag multiple times to increase verbosity.
:) Not exactly what I was thinking - if you have a vector/list value type, doesn't each occurence of an option get appended to it? I wouldn't personally care about min/max; required or optional are enough.
I think that for now you'd have to use .count.
- Volodya
I do, for now. It's not bad, but having the same information twice, in different sections of code, isn't perfect (I need to quit changing my options so much!) -Jon

Michael van der Westhuizen wrote:
Vladimir Prus wrote:
Jonathan Graehl wrote:
I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options.
Does "min/max" number of occurrences makes much sense? In variables_map, an option is either present, or not, it cannot be present twice.
Yes, it does make sense. Two examples I can think of offhand are tcpdump and nmap, both of which allow you to specify the -v flag multiple times to increase verbosity.
That's multiple occurences of a value on the command line. But in variables_map, the option will be present only once -- supposedly, the number of "-v" occurences will be the value of the option. This is just like -I (include path) option. It can be specified several times, but end up as a vector of paths. I think that Jonathan was more interested in "option is required to be present in variables_map" functionality. On a related note, I don't think adding min/max number of occurences for command line is a good idea. That would make interface harder, and is only reasonable for most contrived command lines, and it's possible to enforce this restriction by manipulating parsed_options instance directly. The idea to require some option to be present in variables_map seems reasonable -- it's more common case. - Volodya
participants (4)
-
Jonathan Graehl
-
Jonathan Graehl
-
Michael van der Westhuizen
-
Vladimir Prus