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)