[/ / Copyright (c) 2001, 2002 Peter Dimov and Multi Media Ltd. / Copyright (c) 2003-2005 Peter Dimov / / Distributed under the Boost Software License, Version 1.0. (See / accompanying file LICENSE_1_0.txt or copy at / http://www.boost.org/LICENSE_1_0.txt) /] [section:faq Frequently Asked Questions] [section Can `mem_fn` be used instead of the standard `std::mem_fun[_ref]` adaptors?] Yes. For simple uses, `mem_fn` provides additional functionality that the standard adaptors do not. Complicated expressions that use `std::bind1st`, `std::bind2nd` or [@http://www.boost.org/doc/libs/1_31_0/libs/compose/index.htm Boost.Compose] along with the standard adaptors can be rewritten using `boost::bind` that automatically takes advantage of `mem_fn`. [endsect] [section Should I replace every occurence of `std::mem_fun[_ref]` with `mem_fn` in my existing code?] No, unless you have good reasons to do so. `mem_fn` is not 100% compatible with the standard adaptors, although it comes pretty close. In particular, `mem_fn` does not return objects of type `std::[const_]mem_fun[1][_ref]_t`, as the standard adaptors do, and it is not possible to fully describe the type of the first argument using the standard `argument_type` and `first_argument_type` nested typedefs. Libraries that need adaptable function objects in order to function might not like `mem_fn`. [endsect] [section Does `mem_fn` work with COM methods?] Yes, if you [link mem_fn.implementation.stdcall `#define BOOST_MEM_FN_ENABLE_STDCALL]. [endsect] [section Why isn't `BOOST_MEM_FN_ENABLE_STDCALL` defined automatically?] Non-portable extensions, in general, should default to off to prevent vendor lock-in. Had `BOOST_MEM_FN_ENABLE_STDCALL` been defined automatically, you could have accidentally taken advantage of it without realizing that your code is, perhaps, no longer portable. In addition, it is possible for the default calling convention to be `__stdcall`, in which case enabling `__stdcall` support will result in duplicate definitions. [endsect] [endsect]