54 lines
2.0 KiB
Plaintext
54 lines
2.0 KiB
Plaintext
[/
|
|
/ 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]
|