| Brian Silverman | ce4aa8d | 2018-08-04 23:36:03 -0700 | [diff] [blame^] | 1 | [/ |
| 2 | / Copyright (c) 2001, 2002 Peter Dimov and Multi Media Ltd. |
| 3 | / Copyright (c) 2003-2005 Peter Dimov |
| 4 | / |
| 5 | / Distributed under the Boost Software License, Version 1.0. (See |
| 6 | / accompanying file LICENSE_1_0.txt or copy at |
| 7 | / http://www.boost.org/LICENSE_1_0.txt) |
| 8 | /] |
| 9 | |
| 10 | [section:faq Frequently Asked Questions] |
| 11 | |
| 12 | [section Can `mem_fn` be used instead of the standard `std::mem_fun[_ref]` |
| 13 | adaptors?] |
| 14 | |
| 15 | Yes. For simple uses, `mem_fn` provides additional functionality that the |
| 16 | standard adaptors do not. Complicated expressions that use `std::bind1st`, |
| 17 | `std::bind2nd` or [@http://www.boost.org/doc/libs/1_31_0/libs/compose/index.htm Boost.Compose] |
| 18 | along with the standard adaptors can be rewritten using `boost::bind` that |
| 19 | automatically takes advantage of `mem_fn`. |
| 20 | |
| 21 | [endsect] |
| 22 | |
| 23 | [section Should I replace every occurence of `std::mem_fun[_ref]` with |
| 24 | `mem_fn` in my existing code?] |
| 25 | |
| 26 | No, unless you have good reasons to do so. `mem_fn` is not 100% compatible |
| 27 | with the standard adaptors, although it comes pretty close. In particular, |
| 28 | `mem_fn` does not return objects of type `std::[const_]mem_fun[1][_ref]_t`, as |
| 29 | the standard adaptors do, and it is not possible to fully describe the type of |
| 30 | the first argument using the standard `argument_type` and `first_argument_type` |
| 31 | nested typedefs. Libraries that need adaptable function objects in order to |
| 32 | function might not like `mem_fn`. |
| 33 | |
| 34 | [endsect] |
| 35 | |
| 36 | [section Does `mem_fn` work with COM methods?] |
| 37 | |
| 38 | Yes, if you [link mem_fn.implementation.stdcall `#define BOOST_MEM_FN_ENABLE_STDCALL]. |
| 39 | |
| 40 | [endsect] |
| 41 | |
| 42 | [section Why isn't `BOOST_MEM_FN_ENABLE_STDCALL` defined automatically?] |
| 43 | |
| 44 | Non-portable extensions, in general, should default to off to prevent vendor |
| 45 | lock-in. Had `BOOST_MEM_FN_ENABLE_STDCALL` been defined automatically, you |
| 46 | could have accidentally taken advantage of it without realizing that your code |
| 47 | is, perhaps, no longer portable. In addition, it is possible for the default |
| 48 | calling convention to be `__stdcall`, in which case enabling `__stdcall` |
| 49 | support will result in duplicate definitions. |
| 50 | |
| 51 | [endsect] |
| 52 | |
| 53 | [endsect] |