Squashed 'third_party/boostorg/bind/' content from commit d67200b
Change-Id: I21573b0bd786f4e8482a7bb79a73b7574be6bdae
git-subtree-dir: third_party/boostorg/bind
git-subtree-split: d67200bd2a1f67135a4c677636546ec9615e21ea
diff --git a/doc/mem_fn/faq.qbk b/doc/mem_fn/faq.qbk
new file mode 100644
index 0000000..169c8f1
--- /dev/null
+++ b/doc/mem_fn/faq.qbk
@@ -0,0 +1,53 @@
+[/
+ / 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]