[program_options] setting defaults
Part one: I spent yesterday trying to use a char * to set the default for a string option: opts.add_option("config", "Set the config file to examine", po::value<string>()->default_value("newconfig")); The result was a segmentation fault or illegal instruction during the destruction of my opts class (a wrapper that has several options_descriptions and a positional_options_description; there are methods like the add_option() above that allow various options to be set, in general they put the value_semantic argument last, but otherwise pass arguments directly through). So today I realized that passing a char * to something expecting a std:string might be asking for trouble. So I tried this: string DefaultConfig("newconfig"); opts.add_option("config", "Set the config file to examine", po::value<string>()->default_value(DefaultConfig)); That didn't work any better. Moving the string to global scope didn't help, nor did making it static. So, how do I set the default for a string option? Part two: I want to set up a boolean option (its existence returns true, and if it is not there it returns false). This is done using bool_switch(), I see. However I end up with a segmentation fault if I use this following line: opts.add_option("bool", "testing boolean", po::bool_switch()); The fault occurs, again, when opts' destructor is running. If I leave out the bool_switch() (ie. don't set a value semantic) I get no such error, although the behaviour is not as I'd like it. So, how do I use bool_switch()? What am I missing here? It is possible I'm having trouble with all occurences of po::value<>, as I haven't used it elsewhere yet (I'm adding stuff gradually)... Take care, Liam -- Liam Routt Ph: (03) 8344-1315 Research Programmer caligari@cs.mu.oz.au Computer Science, Melbourne University (or liam@routt.net)
Liam Routt wrote:
The result was a segmentation fault or illegal instruction during the destruction of my opts class (a wrapper that has several options_descriptions and a positional_options_description; there are methods like the add_option() above that allow various options to be set, in general they put the value_semantic argument last, but otherwise pass arguments directly through). ... What am I missing here? It is possible I'm having trouble with all occurences of po::value<>...
OK, I think I'm ready to partially answer my own question. Here's what I have, in simple terms: class Options { ... public: add_option(const char *name, const char *desc, const po::value_semantic *val=NULL) { if ( val != NULL ) { configfile.add_options() (name, val, desc); environ.add_options() (name, val, desc); } else { ... add options without val ... } } ... private: po::options_description configfile; po::options_description environ; }; When I call Options::add_option() and pass a value semantic like value<int>(), that fucntion is called *once* and the result is passed to the add_options for both options_description instances. When they go to clean up, the same value_semantic * is being dealt with by both instances, and that causes a problem. My aim here is to provide a single point of definition for options that should be looked for in multiple locations. If at all possible I want to reduce an option definition to a single line, and preferably I want to hide the specific Boost program options stuff from the level above this (I am using #defines for the value<>() calls). Is there a way I can do this easily? In order to delay the evaluation of value<int>() I suppose I could use a macro rather than a method, perhaps... Hmmm... Take care, Liam -- Liam Routt Ph: (03) 8344-1315 Research Programmer caligari@cs.mu.oz.au Computer Science, Melbourne University (or liam@routt.net)
Liam Routt wrote:
Liam Routt wrote:
The result was a segmentation fault or illegal instruction during the destruction of my opts class (a wrapper that has several options_descriptions and a positional_options_description; there are methods like the add_option() above that allow various options to be set, in general they put the value_semantic argument last, but otherwise pass arguments directly through). ... What am I missing here? It is possible I'm having trouble with all occurences of po::value<>...
OK, I think I'm ready to partially answer my own question.
Here's what I have, in simple terms:
class Options { ... public: add_option(const char *name, const char *desc, const po::value_semantic *val=NULL) { if ( val != NULL ) { configfile.add_options() (name, val, desc); environ.add_options() (name, val, desc); } else { ... add options without val ... } } ... private: po::options_description configfile; po::options_description environ; };
When I call Options::add_option() and pass a value semantic like value<int>(), that fucntion is called *once* and the result is passed to the add_options for both options_description instances. When they go to clean up, the same value_semantic * is being dealt with by both instances, and that causes a problem.
My aim here is to provide a single point of definition for options that should be looked for in multiple locations. If at all possible I want to reduce an option definition to a single line, and preferably I want to hide the specific Boost program options stuff from the level above this (I am using #defines for the value<>() calls). Is there a way I can do this easily?
In order to delay the evaluation of value<int>() I suppose I could use a macro rather than a method, perhaps... Hmmm...
It looks like two alternatives are: - making value<T> return shared_ptr<..> - adding virtual 'clone' method to the value_semantic class. But I'm not yet sure which one is best. - Volodya
participants (2)
-
Liam Routt -
Vladimir Prus