quote:

---

Magmai : You are right, it can be a pain in the ass to create a functor, but with a functor performance is much higher. Because the compiler can inline everything.

---

quote:

---

Original post by Stoffel

Original post by Gorg
mem_fun is suppose to compile to the correct version, mem_fun1, but this only works if the compiler supports Partial template specialization.

---

    template <class S, class T>   class mem_fun_t  : public unary_function<T*,S>  {    S (T::*pmf)();  public:    _EXPLICIT mem_fun_t(S (T::*p)()) : pmf(p)    { ; }    S operator()(T* p) const    { return (p->*pmf)(); }  };  template <class S, class T, class A>   class mem_fun1_t : public binary_function<T*,A,S>  {    S (T::*pmf)(A);  public:    _EXPLICIT mem_fun1_t(S (T::*p)(A)) : pmf(p)    { ; }    S operator()(T* p, A a) const    { return (p->*pmf)(a); }  };  template <class S, class T>   inline mem_fun_t<S,T> mem_fun(S (T::*f)())  {    return mem_fun_t<S,T>(f);  }  template <class S, class T, class A>   inline mem_fun1_t<S,T,A> mem_fun(S (T::*f)(A))  {    return mem_fun1_t<S,T,A>(f);  }    

quote:

---

Original post by Kylotan

Stoffel: I think I see what you mean now. I was expecting mem_fun to return a function object that would be given a single parameter, but in fact it returns a function object that is parameterised by the object it gets called upon. Which makes sense. The fact that the member function required another parameter just made it more complicated, and required the binder object. I think. Anyway, you said "mem_fun calls a member function of Creature*", whereas it looks to me like, in my example, mem_fun was expecting an App* from for_each, and it was actually getting Creature*, hence the error. Is this right?

---

    class Test{ public:    void Print( int i ) const  //need to change void and const to make it build in VC++   {       std::cout << "i" << std::endl;   }};std::vector<Test*> testContainer;//fill the container up//this will print a list of 3for_each( testContainer.begin(),          testContainer.end(),          bind2nd( mem_fun(&Test::print), 3 );//use bind2nd because the function will be called like this :Test::print( testContainer[i], 3 );  

        //uses Test class abovestd::vector<int> intContainter;//fill the vectorTest t;//this will print the list of integer in the vectorfor_each( intContainer.begin(),          intContainer.end(),          bind1st( mem_fun(&Test::print), & t ));//use bind1st, because this pointer is first, so resolve to something likeTest::print( &t, intContainer[i] );    

  std::vector<int> intContainer;//fill the containerTest t;//sorry the var namesstd::bind1st funcBinder( mem_fun(&Test::print), & t );for_each( intContainer.begin(),          intContainer.end(),          funcBinder );  

quote:

---

Original post by Kylotan
All those meaningless variable names for hypothetical parameters does my head in. I can only handle worked examples

---

quote:

---

MKH: "AFAICT, You have to create a new functor for each & every method you want to use with for_each." What''s the problem with this? After all, as was shown in the assembly listing below, when such an object contains no members (99% of the time) it gets optimised away to nothing. And when it does have members, that''s some sort of state that you would have had to preserve anyway. Maybe there''s something I''m missing though, not really being an STL expert.

---

quote:

---

Original post by Magmai Kai Holmlor
I didn''t realize that mem_fun/mem_fun1/bind1st/etc... could create these adaptors for you. I thought you had to code them yourself, I figured there was something that I was missing

---

  #include "algorithm"for_each(humanity.begin(), humanity.end(), end_world_poverty);