[ceph.git] / ceph / src / boost / libs / bind / doc / mem_fn / faq.qbk

[/
 /  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]
Commit	Line	Data
7c673cae FG	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]