[boost] boost::program_options::variables_map question

From: Carmelo Piccione (carmelo.piccione_at_[hidden])
Date: 2006-10-08 18:39:22

Apologize in advance if this is the wrong list for such discussion.

I am very happily using boost::program_options in a work project. I
adopted some conventions from the program_options tutorial, in
particular...

-------------------------------------
boost::program_options::variables_map vm;
...
if (vm.count("foo")) {
..
} else {}
------------------------------

With the idea that if the user specified "foo" on the command line at
least once, then the  if-block would be executed. This usually works.
However I have stumbled on a case where it doesn't. Here is a piece of
the code does that fails :

-----------------------------------------------------------
const std::vector<double> & vec =
vm[PROB_TRIPLE_OPTION_NAME].as<std::vector<double> >();
std::cout << "vector size:" << vec.size() << std::endl;
        
if (vm.count(PROB_TRIPLE_OPTION_NAME)) {
...
} else {..}
--------------------------------------------------

When I run this the size of the vector is 3 and it has the exact
values I wanted from the command line (stored in the 'vec' reference).
However, the if-block is NOT executed.

I was perusing the variables_map code, which inherits count from
std::map<std::string, variable_val>. However variables_map also seems
to have pointers to other variables_maps which it iterates over when
searching (ie. when one uses operator[] to find a value). Thus I
*suspect* that I was assuming count would do something similar, but
instead it only checks the top level variables_map (since it's just
using std::map::count), not any of the other maps the vm instance has
pointers to.

Is this the best behavior for count()? If so should the tutorial
caveat the user about this? Or should one avoid using count() when
writing good program_options code? Or am I completely wrong all
together?

Thanks,
Carmelo

On 10/8/06, Michael Marcin <mike_at_[hidden]> wrote:
> Janek Kozicki wrote:
> > Marcus Lindblom said:     (by the date of Sun, 08 Oct 2006 13:28:56 +0200)
> >
> >> Perhaps we can make it so that you can decouple access style from the
> >> general algorithms? We might need that anyway, if we want to support
> >> things like rgba, stqr, etc, for the small 1-4 element vectors.
> >
> > interesting idea, compare:
> >
> > - iterators <-> continers
> > - member access <-> vectors
> >
> > maybe with MPL it's possible to define that 'custom' access method.
> >
>
> It would be very cool if you could swizzle the components for small
> vectors cheaply into views ala high level shader languages.  I.E.
>
> geom::vector<float,4> vec( 1, 0, 0, 0 );
>
> // replicate x to all channels
> vec = vec.xxxx;
> // vec = { 1, 1, 1, 1 }
>
> or
>
> // convert the result of 3rd party geometry lib based function
> // that uses +y up to a result that a +z up application can use
>
> geom::vector<float,3> some_function();
>
> geom::vector<float,3> app_vec( some_function().xzy );
>
> - Mike
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>