From: Liam Routt (caligari_at_[hidden])
Date: 2005-03-14 20:13:10
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_at_[hidden] Computer Science, Melbourne University (or liam_at_[hidden])