Piyo wrote:
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?
Once std::mem_fn is widely available, there'll be no reason to use boost::mem_fn, except for old compilers. When the list of Boost-supported compilers no longer includes a compiler that doesn't have a std::mem_fn, boost/mem_fn.hpp can be reduced to: #include <functional> namespace boost { using std::mem_fn; }
- 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?
Lack of demand is one reason. Another is that mem_fn has a first argument that cannot be expressed as a typedef. There are probably others.