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:
> > 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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk