Re: Problem with boost::lambda and pointers
 
In article <1156663464.877563.174740@m73g2000cwd.googlegroups.com>,
<"noid@list.ru"> wrote:
Hello everyone! First of all, excuse me for poor english. I will try to
be breif. In my programm I have a std::map<int,
boost::shared_ptr<MyClass> >. The problem is to iterate through this
container using boost::lambda, calling function MyClass::SomeFunction()
for each shared_ptr in a map's pair. Solution like below is not
working:
for_each( Cont.begin(), Cont.end(), bind( &MyCont::value_type::second,
_1 )->SomeFunction() );
How should I write it to make working? Also I am not sure in necessary
"using" directives had to be used.
Thank you!
this works only using boost::bind [or tr1::bind] but note the
complexity, 
struct my_class
{
   int x;
   my_class(int a):x(a){}
   void func() {std::cout << x << '\n';}
};
typedef std::map<int,boost::shared_ptr<my_class> > Map;
Map m;
std::for_each
   (
      m.begin(),
      m.end(),
      boost::bind
      (
         &my_class::func,
         boost::bind
         (
            &boost::shared_ptr<my_class>::get,
            boost::bind(&Map::value_type::second,_1)
         )
      )
   );
looks a bit messy note three appllications of bind, and if this is done
more than once it is a pain to read, etc.  Note I wrote it like above
to make it more readable... 
If you use the bind approach once or twice I do not mind it but if you
are performing this a few times with different algorithms, then prehaps
boost's iterator library [transform_iterator, indirect_iterator come to
mind] will provide a transformation of the iterator which is cleaner.
struct dereference:std::unary_function<my_class &,Map::reference>
{
   my_class & operator () (Map::reference x) const
   {
      return *(x.second);
   }
};
typedef boost::transform_iterator<dereference,Map::iterator> iterator_t;
std::for_each(iterator_t(m.begin()),iterator_t(m.end()),
   boost::bind(&my_class::func,_1));
your choice.   Note allthough not self contained in the for_each
statement the transform_iterator solution is likely to be easier to
read and probably faster to compile and faster to execute unless all
those binds end up inlining all the internal call operators....
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]