|
Boost : |
From: Tarjei Knapstad (tarjei.knapstad_at_[hidden])
Date: 2007-03-20 11:43:14
On 3/20/07, Vladimir Prus <ghost_at_[hidden]> wrote:
> Tom Bachmann wrote:
>
<snip>
>
> > 1 change the values of options in a variables_map
> >
> > The only way to do this (as far as I can see) is the private interface
> > that the store function uses. I currently do
> >
> > const_cast<boost::program_options::variable_value&> (vm[opt -> long_name
> > ()]).value () = val;
> >
> > which is neither clean nor complete (the internal reference to
> > value_semantic is not updated, but this should not be necessary anyway,
> > I think).
> > The easiest fix would be to add a public interface to change the value
> > of an option in a variables map, by making op[] return a non-const
> > reference. I'm not sure if code should be added to call semantic ->
> > notify automically.
>
> Yep, I guess we need non-const-returning[] for sure. We probably should
> have variable_value overload operator=, and call semantic->notify. Do
> you think disallowing assignements that change value type is OK? Say,
> if you try to assign int to value of type double, you get exception.
>
Add me to the list of people trying to make boost::program_options do
a little more than it was originally designed for ;) Just been over
this exact problem today.
Disallowing assignments that change the value type sounds good to me.
You'll probably catch it the way things currently are because
variables_map["option"].as<double>() will throw boost::bad_any_cast
later on when you try to acess the option again, but an exception on
wrongful assignment would be preferable.
Regards,
-- Tarjei
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk