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@mikemarcin.com> 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