[Boost-users] Re: [program_options] setting defaults

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-15 10:44:12

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