feedc0de/boost_bind
1
0
Fork 0
forked from boostorg/bind
Code Pull Requests Activity

mem_fn FAQ updated.

Browse Source 
[SVN r11786]
This commit is contained in:
Peter Dimov
2001-11-27 11:54:25 +00:00
parent 46a32f7547
commit 16a07b2592
1 changed files with 17 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
mem_fn.html
View File

@@ -31,6 +31,8 @@
<b>std::mem_fun[_ref]</b> adaptors?</a></h4>
<h4 style="margin-left: 40pt;"><a href="#Q2">Should I replace every occurence of <b>std::mem_fun[_ref]</b>
with <b>mem_fn</b> in my existing code?</a></h4>
<h4 style="margin-left: 40pt;"><a href="#Q3">Will <b>mem_fn</b> work with COM methods?</a></h4>
<h4 style="margin-left: 40pt;"><a href="#Q4">Why isn't BOOST_MEM_FN_ENABLE_STDCALL defined automatically?</a></h4>
<h3 style="margin-left: 20pt;"><a href="#Interface">Interface</a></h3>
<h4 style="margin-left: 40pt;"><a href="#Synopsis">Synopsis</a></h4>
<h4 style="margin-left: 40pt;"><a href="#CommonRequirements">Common requirements</a></h4>
@@ -194,6 +196,21 @@ that need adaptable function objects in order to function might not like
<b>mem_fn</b>.
</p>
<h3><a name="Q3">Will <b>mem_fn</b> work with COM methods?</a></h3>
<p>
Yes, if you <a href="#stdcall">#define BOOST_MEM_FN_ENABLE_STDCALL</a>.
</p>
<h3><a name="Q4">Why isn't BOOST_MEM_FN_ENABLE_STDCALL defined automatically?</a></h3>
<p>
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.
</p>
<h2><a name="Interface">Interface</a></h2>
<h3><a name="Synopsis">Synopsis</a></h3>