1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
---|
2 | <html> |
---|
3 | <head> |
---|
4 | <title>Boost: mem_fn.hpp documentation</title> |
---|
5 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
---|
6 | </head> |
---|
7 | <body bgcolor="white" style="MARGIN-LEFT: 5%; MARGIN-RIGHT: 5%"> |
---|
8 | <table border="0" width="100%"> |
---|
9 | <tr> |
---|
10 | <td width="277"><A href="../../index.htm"> <img src="../../boost.png" alt="boost.png (6897 bytes)" width="277" height="86" border="0"></A> |
---|
11 | </td> |
---|
12 | <td align="center"> |
---|
13 | <h1>mem_fn.hpp</h1> |
---|
14 | </td> |
---|
15 | </tr> |
---|
16 | <tr> |
---|
17 | <td colspan="2" height="64"> </td> |
---|
18 | </tr> |
---|
19 | </table> |
---|
20 | <h2>Contents</h2> |
---|
21 | <h3 style="MARGIN-LEFT: 20pt"><a href="#Purpose">Purpose</a></h3> |
---|
22 | <h3 style="MARGIN-LEFT: 20pt"><a href="#FAQ">Frequently Asked Questions</a></h3> |
---|
23 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Q1">Can <b>mem_fn</b> be used instead of the |
---|
24 | standard <b>std::mem_fun[_ref]</b> adaptors?</a></h4> |
---|
25 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Q2">Should I replace every occurence of <b>std::mem_fun[_ref]</b> |
---|
26 | with <b>mem_fn</b> in my existing code?</a></h4> |
---|
27 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Q3">Does <b>mem_fn</b> work with COM methods?</a></h4> |
---|
28 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Q4">Why isn't BOOST_MEM_FN_ENABLE_STDCALL |
---|
29 | defined automatically?</a></h4> |
---|
30 | <h3 style="MARGIN-LEFT: 20pt"><a href="#Interface">Interface</a></h3> |
---|
31 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Synopsis">Synopsis</a></h4> |
---|
32 | <h4 style="MARGIN-LEFT: 40pt"><a href="#CommonRequirements">Common requirements</a></h4> |
---|
33 | <h4 style="MARGIN-LEFT: 40pt"><a href="#get_pointer">get_pointer</a></h4> |
---|
34 | <h4 style="MARGIN-LEFT: 40pt"><a href="#mem_fn">mem_fn</a></h4> |
---|
35 | <h3 style="MARGIN-LEFT: 20pt"><a href="#Implementation">Implementation</a></h3> |
---|
36 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Files">Files</a></h4> |
---|
37 | <h4 style="MARGIN-LEFT: 40pt"><a href="#Dependencies">Dependencies</a></h4> |
---|
38 | <h4 style="MARGIN-LEFT: 40pt"><a href="#NumberOfArguments">Number of Arguments</a></h4> |
---|
39 | <h4 style="MARGIN-LEFT: 40pt"><a href="#stdcall">"__stdcall", "__cdecl" and |
---|
40 | "__fastcall" Support</a></h4> |
---|
41 | <h3 style="MARGIN-LEFT: 20pt"><a href="#Acknowledgements">Acknowledgements</a></h3> |
---|
42 | <h2><a name="Purpose">Purpose</a></h2> |
---|
43 | <p> |
---|
44 | <b>boost::mem_fn</b> is a generalization of the standard functions <b>std::mem_fun</b> |
---|
45 | and <b>std::mem_fun_ref</b>. It supports member function pointers with more |
---|
46 | than one argument, and the returned function object can take a pointer, a |
---|
47 | reference, or a smart pointer to an object instance as its first argument. <STRONG>mem_fn</STRONG> |
---|
48 | also supports pointers to data members by treating them as functions taking no |
---|
49 | arguments and returning a (const) reference to the member. |
---|
50 | </p> |
---|
51 | <p> |
---|
52 | The purpose of <b>mem_fn</b> is twofold. First, it allows users to invoke a |
---|
53 | member function on a container with the familiar |
---|
54 | </p> |
---|
55 | <pre> |
---|
56 | std::for_each(v.begin(), v.end(), boost::mem_fn(&Shape::draw)); |
---|
57 | </pre> |
---|
58 | <p> |
---|
59 | syntax, even when the container stores smart pointers. |
---|
60 | </p> |
---|
61 | <p> |
---|
62 | Second, it can be used as a building block by library developers that want to |
---|
63 | treat a pointer to member function as a function object. A library might define |
---|
64 | an enhanced <b>for_each</b> algorithm with an overload of the form: |
---|
65 | </p> |
---|
66 | <pre> |
---|
67 | template<class It, class R, class T> void for_each(It first, It last, R (T::*pmf) ()) |
---|
68 | { |
---|
69 | std::for_each(first, last, boost::mem_fn(pmf)); |
---|
70 | } |
---|
71 | </pre> |
---|
72 | <p> |
---|
73 | that will allow the convenient syntax: |
---|
74 | </p> |
---|
75 | <pre> |
---|
76 | for_each(v.begin(), v.end(), &Shape::draw); |
---|
77 | </pre> |
---|
78 | <p> |
---|
79 | When documenting the feature, the library author will simply state: |
---|
80 | </p> |
---|
81 | <h4 style="MARGIN-LEFT: 20pt">template<class It, class R, class T> void |
---|
82 | for_each(It first, It last, R (T::*pmf) ());</h4> |
---|
83 | <p style="MARGIN-LEFT: 20pt"> |
---|
84 | <b>Effects:</b> equivalent to std::for_each(first, last, boost::mem_fn(pmf)); |
---|
85 | </p> |
---|
86 | <p> |
---|
87 | where <b>boost::mem_fn</b> can be a link to this page. See <a href="bind.html">the |
---|
88 | documentation of <b>bind</b></a> for an example. |
---|
89 | </p> |
---|
90 | <p> |
---|
91 | <b>mem_fn</b> takes one argument, a pointer to a member, and returns a function |
---|
92 | object suitable for use with standard or user-defined algorithms: |
---|
93 | </p> |
---|
94 | <pre> |
---|
95 | struct X |
---|
96 | { |
---|
97 | void f(); |
---|
98 | }; |
---|
99 | |
---|
100 | void g(std::vector<X> & v) |
---|
101 | { |
---|
102 | std::for_each(v.begin(), v.end(), boost::mem_fn(&X::f)); |
---|
103 | }; |
---|
104 | |
---|
105 | void h(std::vector<X *> const & v) |
---|
106 | { |
---|
107 | std::for_each(v.begin(), v.end(), boost::mem_fn(&X::f)); |
---|
108 | }; |
---|
109 | |
---|
110 | void k(std::vector<boost::shared_ptr<X> > const & v) |
---|
111 | { |
---|
112 | std::for_each(v.begin(), v.end(), boost::mem_fn(&X::f)); |
---|
113 | }; |
---|
114 | </pre> |
---|
115 | <p> |
---|
116 | The returned function object takes the same arguments as the input member |
---|
117 | function plus a "flexible" first argument that represents the object instance. |
---|
118 | </p> |
---|
119 | <p> |
---|
120 | When the function object is invoked with a first argument <b>x</b> that is |
---|
121 | neither a pointer nor a reference to the appropriate class (<b>X</b> in the |
---|
122 | example above), it uses <tt>get_pointer(x)</tt> to obtain a pointer from <b>x</b>. |
---|
123 | Library authors can "register" their smart pointer classes by supplying an |
---|
124 | appropriate <b>get_pointer</b> overload, allowing <b>mem_fn</b> to recognize |
---|
125 | and support them. |
---|
126 | </p> |
---|
127 | <p> |
---|
128 | [Note: <b>get_pointer</b> is not restricted to return a pointer. Any object |
---|
129 | that can be used in a member function call expression <tt>(x->*pmf)(...)</tt> |
---|
130 | will work.] |
---|
131 | </p> |
---|
132 | <p> |
---|
133 | [Note: the library uses an unqualified call to <b>get_pointer</b>. Therefore, |
---|
134 | it will find, through argument-dependent lookup, <b>get_pointer</b> overloads |
---|
135 | that are defined in the same namespace as the corresponding smart pointer |
---|
136 | class, in addition to any <b>boost::get_pointer</b> overloads.] |
---|
137 | </p> |
---|
138 | <p> |
---|
139 | All function objects returned by <b>mem_fn</b> expose a <b>result_type</b> typedef |
---|
140 | that represents the return type of the member function. For data members, <STRONG>result_type</STRONG> |
---|
141 | is defined as the type of the member. |
---|
142 | </p> |
---|
143 | <h2><a name="FAQ">Frequently Asked Questions</a></h2> |
---|
144 | <h3><a name="Q1">Can <b>mem_fn</b> be used instead of the standard <b>std::mem_fun[_ref]</b> |
---|
145 | adaptors?</a></h3> |
---|
146 | <p> |
---|
147 | Yes. For simple uses, <b>mem_fn</b> provides additional functionality that the |
---|
148 | standard adaptors do not. Complicated expressions that use <b>std::bind1st</b>, <b>std::bind2nd</b> |
---|
149 | or <a href="../compose/index.htm"><b>Boost.Compose</b></a> along with the |
---|
150 | standard adaptors can be rewritten using <a href="bind.html"><b>boost::bind</b></a> |
---|
151 | that automatically takes advantage of <b>mem_fn</b>. |
---|
152 | </p> |
---|
153 | <h3><a name="Q2">Should I replace every occurence of <b>std::mem_fun[_ref]</b> with <b>mem_fn</b> |
---|
154 | in my existing code?</a></h3> |
---|
155 | <p> |
---|
156 | No, unless you have good reasons to do so. <b>mem_fn</b> is not 100% compatible |
---|
157 | with the standard adaptors, although it comes pretty close. In particular, <b>mem_fn</b> |
---|
158 | does not return objects of type <b>std::[const_]mem_fun[1][_ref]_t</b>, as the |
---|
159 | standard adaptors do, and it is not possible to fully describe the type of the |
---|
160 | first argument using the standard <b>argument_type</b> and <b>first_argument_type</b> |
---|
161 | nested typedefs. Libraries that need adaptable function objects in order to |
---|
162 | function might not like <b>mem_fn</b>. |
---|
163 | </p> |
---|
164 | <h3><a name="Q3">Does <b>mem_fn</b> work with COM methods?</a></h3> |
---|
165 | <p> |
---|
166 | Yes, if you <a href="#stdcall">#define BOOST_MEM_FN_ENABLE_STDCALL</a>. |
---|
167 | </p> |
---|
168 | <h3><a name="Q4">Why isn't BOOST_MEM_FN_ENABLE_STDCALL defined automatically?</a></h3> |
---|
169 | <p> |
---|
170 | Non-portable extensions, in general, should default to off to prevent vendor |
---|
171 | lock-in. Had BOOST_MEM_FN_ENABLE_STDCALL been defined automatically, you could |
---|
172 | have accidentally taken advantage of it without realizing that your code is, |
---|
173 | perhaps, no longer portable. In addition, it is possible for the default |
---|
174 | calling convention to be __stdcall, in which case enabling __stdcall support |
---|
175 | will result in duplicate definitions. |
---|
176 | </p> |
---|
177 | <h2><a name="Interface">Interface</a></h2> |
---|
178 | <h3><a name="Synopsis">Synopsis</a></h3> |
---|
179 | <pre> |
---|
180 | namespace boost |
---|
181 | { |
---|
182 | |
---|
183 | template<class T> T * <a href="#get_pointer_1">get_pointer</a>(T * p); |
---|
184 | |
---|
185 | template<class R, class T> <i>unspecified-1</i> <a href="#mem_fn_1">mem_fn</a>(R (T::*pmf) ()); |
---|
186 | |
---|
187 | template<class R, class T> <i>unspecified-2</i> <a href="#mem_fn_2">mem_fn</a>(R (T::*pmf) () const); |
---|
188 | |
---|
189 | template<class R, class T> <i>unspecified-2-1</i> <a href="#mem_fn_2_1">mem_fn</a>(R T::*pm); |
---|
190 | |
---|
191 | template<class R, class T, class A1> <i>unspecified-3</i> <a href="#mem_fn_3">mem_fn</a>(R (T::*pmf) (A1)); |
---|
192 | |
---|
193 | template<class R, class T, class A1> <i>unspecified-4</i> <a href="#mem_fn_4">mem_fn</a>(R (T::*pmf) (A1) const); |
---|
194 | |
---|
195 | template<class R, class T, class A1, class A2> <i>unspecified-5</i> <a href="#mem_fn_5">mem_fn</a>(R (T::*pmf) (A1, A2)); |
---|
196 | |
---|
197 | template<class R, class T, class A1, class A2> <i>unspecified-6</i> <a href="#mem_fn_6">mem_fn</a>(R (T::*pmf) (A1, A2) const); |
---|
198 | |
---|
199 | // implementation defined number of additional overloads for more arguments |
---|
200 | |
---|
201 | } |
---|
202 | </pre> |
---|
203 | <h3><a name="CommonRequirements">Common requirements</a></h3> |
---|
204 | <p> |
---|
205 | All <tt><i>unspecified-N</i></tt> types mentioned in the Synopsis are <b>CopyConstructible</b> |
---|
206 | and <b>Assignable</b>. Their copy constructors and assignment operators do not |
---|
207 | throw exceptions. <tt><i>unspecified-N</i>::result_type</tt> is defined as the |
---|
208 | return type of the member function pointer passed as an argument to <b>mem_fn</b> |
---|
209 | (<b>R</b> in the Synopsis.) <tt><i>unspecified-2-1</i>::result_type</tt> is |
---|
210 | defined as <tt>R</tt>. |
---|
211 | </p> |
---|
212 | <h3><a name="get_pointer">get_pointer</a></h3> |
---|
213 | <h4><a name="get_pointer_1">template<class T> T * get_pointer(T * p)</a></h4> |
---|
214 | <blockquote> |
---|
215 | <p> |
---|
216 | <b>Returns:</b> <tt>p</tt>. |
---|
217 | </p> |
---|
218 | <p> |
---|
219 | <b>Throws:</b> Nothing. |
---|
220 | </p> |
---|
221 | </blockquote> |
---|
222 | <h3><a name="mem_fn">mem_fn</a></h3> |
---|
223 | <h4><a name="mem_fn_1">template<class R, class T> <i>unspecified-1</i> mem_fn(R |
---|
224 | (T::*pmf) ())</a></h4> |
---|
225 | <blockquote> |
---|
226 | <p> |
---|
227 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t)</i></tt> |
---|
228 | is equivalent to <tt>(t.*pmf)()</tt> when <i>t</i> is an l-value of type <STRONG>T </STRONG> |
---|
229 | or derived, <tt>(get_pointer(t)->*pmf)()</tt> otherwise. |
---|
230 | </p> |
---|
231 | <p> |
---|
232 | <b>Throws:</b> Nothing. |
---|
233 | </p> |
---|
234 | </blockquote> |
---|
235 | <h4><a name="mem_fn_2">template<class R, class T> <i>unspecified-2</i> mem_fn(R |
---|
236 | (T::*pmf) () const)</a></h4> |
---|
237 | <blockquote> |
---|
238 | <p> |
---|
239 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t)</i></tt> |
---|
240 | is equivalent to <tt>(t.*pmf)()</tt> when <i>t</i> is of type <STRONG>T</STRONG> |
---|
241 | <EM>[const]<STRONG> </STRONG></EM>or derived, <tt>(get_pointer(t)->*pmf)()</tt> |
---|
242 | otherwise. |
---|
243 | </p> |
---|
244 | <p> |
---|
245 | <b>Throws:</b> Nothing. |
---|
246 | </p> |
---|
247 | </blockquote> |
---|
248 | <h4><a name="mem_fn_2_1">template<class R, class T> <i>unspecified-2-1</i> mem_fn(R |
---|
249 | T::*pm)</a></h4> |
---|
250 | <blockquote> |
---|
251 | <p> |
---|
252 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t)</i></tt> |
---|
253 | is equivalent to <tt>t.*pm</tt> when <i>t</i> is of type <STRONG>T</STRONG> <EM>[const]<STRONG> |
---|
254 | </STRONG></EM>or derived, <tt>get_pointer(t)->*pm</tt> otherwise. |
---|
255 | </p> |
---|
256 | <p> |
---|
257 | <b>Throws:</b> Nothing. |
---|
258 | </p> |
---|
259 | </blockquote> |
---|
260 | <h4><a name="mem_fn_3">template<class R, class T, class A1> <i>unspecified-3</i> mem_fn(R |
---|
261 | (T::*pmf) (A1))</a></h4> |
---|
262 | <blockquote> |
---|
263 | <p> |
---|
264 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t, a1)</i></tt> |
---|
265 | is equivalent to <tt>(t.*pmf)(a1)</tt> when <i>t</i> is an l-value of type <STRONG>T |
---|
266 | </STRONG>or derived, <tt>(get_pointer(t)->*pmf)(a1)</tt> otherwise. |
---|
267 | </p> |
---|
268 | <p> |
---|
269 | <b>Throws:</b> Nothing. |
---|
270 | </p> |
---|
271 | </blockquote> |
---|
272 | <h4><a name="mem_fn_4">template<class R, class T, class A1> <i>unspecified-4</i> mem_fn(R |
---|
273 | (T::*pmf) (A1) const)</a></h4> |
---|
274 | <blockquote> |
---|
275 | <p> |
---|
276 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t, a1)</i></tt> |
---|
277 | is equivalent to <tt>(t.*pmf)(a1)</tt> when <i>t</i> is of type <STRONG>T</STRONG> |
---|
278 | <EM>[const]<STRONG> </STRONG></EM>or derived, <tt>(get_pointer(t)->*pmf)(a1)</tt> |
---|
279 | otherwise. |
---|
280 | </p> |
---|
281 | <p> |
---|
282 | <b>Throws:</b> Nothing. |
---|
283 | </p> |
---|
284 | </blockquote> |
---|
285 | <h4><a name="mem_fn_5">template<class R, class T, class A1, class A2> <i>unspecified-5</i> |
---|
286 | mem_fn(R (T::*pmf) (A1, A2))</a></h4> |
---|
287 | <blockquote> |
---|
288 | <p> |
---|
289 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t, a1, a2)</i></tt> |
---|
290 | is equivalent to <tt>(t.*pmf)(a1, a2)</tt> when <i>t</i> is an l-value of type <STRONG> |
---|
291 | T</STRONG> or derived, <tt>(get_pointer(t)->*pmf)(a1, a2)</tt> otherwise. |
---|
292 | </p> |
---|
293 | <p> |
---|
294 | <b>Throws:</b> Nothing. |
---|
295 | </p> |
---|
296 | </blockquote> |
---|
297 | <h4><a name="mem_fn_6">template<class R, class T, class A1, class A2> <i>unspecified-6</i> |
---|
298 | mem_fn(R (T::*pmf) (A1, A2) const)</a></h4> |
---|
299 | <blockquote> |
---|
300 | <p> |
---|
301 | <b>Returns:</b> a function object <i>f</i> such that the expression <tt><i>f(t, a1, a2)</i></tt> |
---|
302 | is equivalent to <tt>(t.*pmf)(a1, a2)</tt> when <i>t</i> is of type <STRONG>T</STRONG> |
---|
303 | <EM>[const]</EM> or derived, <tt>(get_pointer(t)->*pmf)(a1, a2)</tt> otherwise. |
---|
304 | </p> |
---|
305 | <p> |
---|
306 | <b>Throws:</b> Nothing. |
---|
307 | </p> |
---|
308 | </blockquote> |
---|
309 | <h2><a name="Implementation">Implementation</a></h2> |
---|
310 | <h3><a name="Files">Files</a></h3> |
---|
311 | <ul> |
---|
312 | <li> |
---|
313 | <a href="../../boost/mem_fn.hpp">boost/mem_fn.hpp</a> |
---|
314 | (main header) |
---|
315 | <li> |
---|
316 | <a href="../../boost/bind/mem_fn_cc.hpp">boost/bind/mem_fn_cc.hpp</a> |
---|
317 | (used by mem_fn.hpp, do not include directly) |
---|
318 | <li> |
---|
319 | <a href="../../boost/bind/mem_fn_vw.hpp">boost/bind/mem_fn_vw.hpp</a> |
---|
320 | (used by mem_fn.hpp, do not include directly) |
---|
321 | <li> |
---|
322 | <a href="../../boost/bind/mem_fn_template.hpp">boost/bind/mem_fn_template.hpp</a> |
---|
323 | (used by mem_fn.hpp, do not include directly) |
---|
324 | <li> |
---|
325 | <a href="test/mem_fn_test.cpp">libs/bind/test/mem_fn_test.cpp</a> |
---|
326 | (test) |
---|
327 | <li> |
---|
328 | <a href="test/mem_fn_derived_test.cpp">libs/bind/test/mem_fn_derived_test.cpp</a> |
---|
329 | (test with derived objects) |
---|
330 | <li> |
---|
331 | <a href="test/mem_fn_fastcall_test.cpp">libs/bind/test/mem_fn_fastcall_test.cpp</a> |
---|
332 | (test for __fastcall) |
---|
333 | <li> |
---|
334 | <a href="test/mem_fn_stdcall_test.cpp">libs/bind/test/mem_fn_stdcall_test.cpp</a> |
---|
335 | (test for __stdcall) |
---|
336 | <li> |
---|
337 | <a href="test/mem_fn_void_test.cpp">libs/bind/test/mem_fn_void_test.cpp</a> (test |
---|
338 | for void returns)</li> |
---|
339 | </ul> |
---|
340 | <h3><a name="Dependencies">Dependencies</a></h3> |
---|
341 | <ul> |
---|
342 | <li> |
---|
343 | <a href="../config/config.htm">Boost.Config</a></li> |
---|
344 | </ul> |
---|
345 | <h3><a name="NumberOfArguments">Number of Arguments</a></h3> |
---|
346 | <p> |
---|
347 | This implementation supports member functions with up to eight arguments. This |
---|
348 | is not an inherent limitation of the design, but an implementation detail. |
---|
349 | </p> |
---|
350 | <h3><a name="stdcall">"__stdcall", "__cdecl" and "__fastcall" Support</a></h3> |
---|
351 | <p> |
---|
352 | Some platforms allow several types of member functions that differ by their <b>calling |
---|
353 | convention</b> (the rules by which the function is invoked: how are |
---|
354 | arguments passed, how is the return value handled, and who cleans up the stack |
---|
355 | - if any.) |
---|
356 | </p> |
---|
357 | <p> |
---|
358 | For example, Windows API functions and COM interface member functions use a |
---|
359 | calling convention known as <b>__stdcall</b>. Borland VCL components use <STRONG>__fastcall</STRONG>. |
---|
360 | UDK, the component model of OpenOffice.org, uses <STRONG>__cdecl</STRONG>. |
---|
361 | </p> |
---|
362 | <p> |
---|
363 | To use <b>mem_fn</b> with <b>__stdcall</b> member functions, <b>#define</b> the |
---|
364 | macro <b>BOOST_MEM_FN_ENABLE_STDCALL</b> before including, directly or |
---|
365 | indirectly, <b><boost/mem_fn.hpp></b>. |
---|
366 | </p> |
---|
367 | <P>To use <B>mem_fn</B> with <B>__fastcall</B> member functions, <B>#define</B> the |
---|
368 | macro <B>BOOST_MEM_FN_ENABLE_FASTCALL</B> before including <B><boost/mem_fn.hpp></B>. |
---|
369 | </P> |
---|
370 | <P>To use <B>mem_fn</B> with <B>__cdecl</B> member functions, <B>#define</B> the |
---|
371 | macro <B>BOOST_MEM_FN_ENABLE_CDECL</B> before including <B><boost/mem_fn.hpp></B>. |
---|
372 | </P> |
---|
373 | <P><STRONG>It is best to define these macros in the project options, via -D on the |
---|
374 | command line, or as the first line in the translation unit (.cpp file) where |
---|
375 | mem_fn is used.</STRONG> Not following this rule can lead to obscure errors |
---|
376 | when a header includes mem_fn.hpp before the macro has been defined.</P> |
---|
377 | <P>[Note: this is a non-portable extension. It is not part of the interface.] |
---|
378 | </P> |
---|
379 | <p> |
---|
380 | [Note: Some compilers provide only minimal support for the <b>__stdcall</b> keyword.] |
---|
381 | </p> |
---|
382 | <h2><a name="Acknowledgements">Acknowledgements</a></h2> |
---|
383 | <p> |
---|
384 | Rene Jager's initial suggestion of using traits classes to make <b>mem_fn</b> adapt |
---|
385 | to user-defined smart pointers inspired the <b>get_pointer</b>-based design. |
---|
386 | </p> |
---|
387 | <p> |
---|
388 | Numerous improvements were suggested during the formal review period by Richard |
---|
389 | Crossley, Jens Maurer, Ed Brey, and others. Review manager was Darin Adler. |
---|
390 | </p> |
---|
391 | <p> |
---|
392 | Steve Anichini pointed out that COM interfaces use <b>__stdcall</b>. |
---|
393 | </p> |
---|
394 | <p> |
---|
395 | Dave Abrahams modified <b>bind</b> and <b>mem_fn</b> to support void returns on |
---|
396 | deficient compilers. |
---|
397 | </p> |
---|
398 | <p>Daniel Boelzle pointed out that UDK uses <STRONG>__cdecl</STRONG>.<br> |
---|
399 | <br> |
---|
400 | <br> |
---|
401 | <small>Copyright © 2001, 2002 by Peter Dimov and Multi Media Ltd. Copyright |
---|
402 | 2003-2005 Peter Dimov. Distributed under the Boost Software License, Version |
---|
403 | 1.0. See accompanying file <A href="../../LICENSE_1_0.txt">LICENSE_1_0.txt</A> or |
---|
404 | copy at <A href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</A>.</small></p> |
---|
405 | </body> |
---|
406 | </html> |
---|