| [/ |
| / 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] |