program_options: main and other translation units
Hello, I have a main.cpp translation unit with the main(int argc, char* argv[]) function. My application runs in 1 of 4 modes. The mode is selected by the command line options, something like --mode1 --mode2 --mode3 --mode4 In main(), I have defined a mode_options instance of options_description, added these modes to it and defined the variables_map 'vm' that will be passed around to functions (1 for each mode) that reside in other translation units. I then get to a try/catch block, where: I store( command_line_parser(argc, argv).options(mode_options).run(), vm ); notify(vm); I have a sanity check that only 1 and at least 1 of the 4 modes is selected. I then call the function relevant to the mode selected, and pass to it 'vm'. In each of these other functions, I have other instances of options_description, reuse the same 'vm' and store again in vm the parsing ran on the appropriate options_description instance. Each mode option has specific suboptions. Question 1: I want the help option to print usage for all modes and all suboptions if no mode is selected. I want the help option to print usage for just 1 mode if a mode is selected. Question 2: I still want to program_options to throw if an unrecognized option is input, however, I throw my own exceptions if an option for mode_i is set with --mode_j for e.g. Question 3: I may eventually move to a GUI (probably c#-based) for passing options. Is there any particular advice to isolate the machinery of program_options from the functional part of my application. A big thanks to the library developer(s) and to the mailing list contributors for all the useful answers. Best regards, H
Am 10.12.2009 15:35, schrieb Hicham Mouline:
Hello,
I have a main.cpp translation unit with the main(int argc, char* argv[]) function. My application runs in 1 of 4 modes. The mode is selected by the command line options, something like
--mode1 --mode2 --mode3 --mode4
In main(), I have defined a mode_options instance of options_description, added these modes to it and defined the variables_map 'vm' that will be passed around to functions (1 for each mode) that reside in other translation units.
I then get to a try/catch block, where:
I store( command_line_parser(argc, argv).options(mode_options).run(), vm ); notify(vm);
I have a sanity check that only 1 and at least 1 of the 4 modes is selected.
I then call the function relevant to the mode selected, and pass to it 'vm'.
In each of these other functions, I have other instances of options_description, reuse the same 'vm' and store again in vm the parsing ran on the appropriate options_description instance. Each mode option has specific suboptions.
Hi, I didn't tried the following out... but it should work.
Question 2: I still want to program_options to throw if an unrecognized option is input, however, I throw my own exceptions if an option for mode_i is set with --mode_j for e.g.
I would propose to have an options_description object for each mode and an additional one for the top level (used to determine which mode occured). The top level description should ignore all unknown option. You first then parse the command line using this top level description and figure out which mode was set. Then pass the command line to a parser together with the specific mode description.
Question 1: I want the help option to print usage for all modes and all suboptions if no mode is selected. I want the help option to print usage for just 1 mode if a mode is selected.
Loop over all option descriptions (see Question 1) and print them out.
vector
Question 3: I may eventually move to a GUI (probably c#-based) for passing options. Is there any particular advice to isolate the machinery of program_options from the functional part of my application.
Do whatever you like to make the option source exchangeable. E.g. an abstract base class Options with two derived classes: CmdlineOptions and GUIOptions. But this is just one possibility. Hope that helps, Cheers, Sascha
A big thanks to the library developer(s) and to the mailing list contributors for all the useful answers. Best regards,
H
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Hicham Mouline
-
Sascha Ochsenknecht