Peter Dimov wrote:
I'm somewhat reluctant to introduce features into boost::mem_fn since std::tr1::mem_fn and the upcoming std::mem_fn don't/won't have them. If you start using ::argN_type, you won't be able to switch to std::mem_fn once it becomes available. Of course if this is not a concern for the Boost community we can easily add the typedefs and the arity.
Hi Peter, Several questions: - when C++0x gets published and when compilers are fully tr1 compliant, do you see boost::mem_fn (and the rest of the tr1 overlap) go away from boost? - I was also interested into the rationale why it was omitted also. I was looking at the mem_fn tr1 proposal and noticed that argN_types were not mentioned. Was it simply because no one so far wanted it? Also, just to complement Marcus's use case, here is a real-world (simplified) use-case that my co-worker is encountering. ---------------------------------------------------------------------- template <typename BaseClassType> class ClassPool { public : void addClass(const std::string &key, BaseClassType *instance) { m_objectMap[key] = instance; } template <typename MemFnType> void executeMemberFunction(const std::string &key, MemFnType memFn) { //here is where we need the class type of the member fn typedef MemFnType::ClassType DerivedType; //we need to dynamic cast to the derived type so we can call //the member function on it typename DerivedType *derivedObject = dynamic_cast< DerivedType *>(m_objectMap[key]); //call the member function memFn(derivedObject); } std::map<std::string, BaseClassType *> m_objectMap; }; class BaseClass { }; class DerivedClass : public BaseClass { void someFunction() {}; }; void main() { ClassPool<BaseClass> classPool; classPool.addClass("SomeObject",new DerivedClass); classPool.executeMemberFunction("SomeObject",boost::mem_fn(someFunction)); }