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