Mutually exclusive options in boost::program_options?
I'm trying to use boost::program_options for the first time, and there's a couple things that I am tripping over. The first is the idea of mutually exclusive options. I can't find any support for them in the library, and that surprises me - to the point of asking for help. I have two options, only one of which can be specified; say -frtti and -fno_rtti (say). The other one is that program_options, by default, wants to use double hyphens to define options: "foo --option1 --option2" I'm a lot more comfortable with single hyphens: "foo -option1 -option2" Am I missing something basic here? -- -- Marshall Marshall Clow Idio Software mailto:marshall@idio.com It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Marshall Clow wrote:
I'm trying to use boost::program_options for the first time, and there's a couple things that I am tripping over.
The first is the idea of mutually exclusive options. I can't find any support for them in the library, and that surprises me - to the point of asking for help.
I have two options, only one of which can be specified; say -frtti and -fno_rtti (say).
The simplest way for this to work is to define a single bool option "rtti". Then, use custom parsers to translate "frtti" and "fno_rtti" to "rtti=off" and "rtti=on" respectively. See http://boost.org/doc/html/program_options/howto.html#id2715843 which discusses exactly this "no" prefix handling. As a side effect users will be able to specity "--rtti=on", but maybe that's not a big problem.
The other one is that program_options, by default, wants to use double hyphens to define options: "foo --option1 --option2"
I'm a lot more comfortable with single hyphens: "foo -option1 -option2"
Am I missing something basic here?
Yes, I think so. The third parameter of 'parse_command_line' is called style, and possible values are listed at: http://boost.org/doc/html/id2358254.html (not very nicely, but that's Bookbook fault). Say, passing default_style|allow_long_disguise should make program_option check for long option even if you specify a single dash. - Volodya
At 10:11 AM +0300 12/20/05, Vladimir Prus wrote:
Marshall Clow wrote:
I'm trying to use boost::program_options for the first time, and there's a couple things that I am tripping over.
The first is the idea of mutually exclusive options. I can't find any support for them in the library, and that surprises me - to the point of asking for help.
I have two options, only one of which can be specified; say -frtti and -fno_rtti (say).
The simplest way for this to work is to define a single bool option "rtti". Then, use custom parsers to translate "frtti" and "fno_rtti" to "rtti=off" and "rtti=on" respectively. See http://boost.org/doc/html/program_options/howto.html#id2715843 which discusses exactly this "no" prefix handling. As a side effect users will be able to specity "--rtti=on", but maybe that's not a big problem.
Ok - I can see how that works, but I think I chose a bad example. Here's a different one: My program has three reporting "modes": Normal -- print out some stuff Quiet -- print nothing Verbose -- print lots of stuff. I need to respond to switches like "--quiet" and "--verbose", which is fine, but I more than one of them in the same command line is an error. I can certainly check in my code to see if more than one was presented (and I will do that); I am just surprised that this functionality is not part of the program-options library. Maybe in a future version. ;-) Thanks for the response! -- -- Marshall Marshall Clow Idio Software mailto:marshall@idio.com It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Marshall Clow wrote:
The simplest way for this to work is to define a single bool option "rtti". Then, use custom parsers to translate "frtti" and "fno_rtti" to "rtti=off" and "rtti=on" respectively. See http://boost.org/doc/html/program_options/howto.html#id2715843 which discusses exactly this "no" prefix handling. As a side effect users will be able to specity "--rtti=on", but maybe that's not a big problem.
Ok - I can see how that works, but I think I chose a bad example. Here's a different one:
My program has three reporting "modes": Normal -- print out some stuff Quiet -- print nothing Verbose -- print lots of stuff.
I need to respond to switches like "--quiet" and "--verbose", which is fine, but I more than one of them in the same command line is an error.
I can certainly check in my code to see if more than one was presented (and I will do that); I am just surprised that this functionality is not part of the program-options library.
Maybe in a future version. ;-)
Maybe. If you look at libs/program_options/example/real.cpp you'll see that I expected conflicting options to be handled by defining a function 'conflicting_options' and using it as appropriate. That still seems a good interface for me. Say: conflicting_options(vm, "normal", "quiet", "verbose"); is not worse IMO then: desc.conflicting_options() ("normal", "quiet", "verbose"); or any other syntax I can invent. It might be reasonable to expect such "conflicting_option" function to be part of library, though. - Volodya
participants (2)
-
Marshall Clow -
Vladimir Prus