]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | <html> |
2 | <head> | |
3 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> | |
4 | <title>Header boost/utility.hpp Documentation</title> | |
5 | </head> | |
6 | <body bgcolor="#FFFFFF" text="#000000"> | |
7 | <h1><img src="../../boost.png" alt="boost.png (6897 bytes)" align="center" WIDTH="277" HEIGHT="86">Header | |
8 | <a href="../../boost/utility.hpp">boost/utility.hpp</a></h1> | |
9 | <p>The entire contents of the header <code><a href="../../boost/utility.hpp"><boost/utility.hpp></a></code> | |
10 | are in <code>namespace boost</code>.</p> | |
11 | <h2>Contents</h2> | |
12 | <ul> | |
13 | <li> | |
14 | Class templates supporting the <a href="doc/html/base_from_member.html"> | |
15 | base-from-member idiom</a></li> | |
16 | <li> | |
17 | Function templates <a href="../core/doc/html/core/checked_delete.html">checked_delete() and | |
18 | checked_array_delete()</a> (moved to the Boost.Core library)</li> | |
19 | <li> | |
20 | Function templates <a href="#functions_next_prior">next() and prior()</a></li> | |
21 | <li> | |
22 | Class <a href="../core/doc/html/core/noncopyable.html">noncopyable</a> (moved to the Boost.Core library)</li> | |
23 | <li> | |
24 | Function template <a href="../core/doc/html/core/addressof.html">addressof()</a> (moved to the Boost.Core library)</li> | |
25 | <li>Class template <a href="#result_of">result_of</a></li> | |
26 | <li> | |
27 | Macro <a href="#BOOST_BINARY">BOOST_BINARY</a></li> | |
28 | <li><a href="index.html">Other utilities not part of <code>utility.hpp</code></a></li> | |
29 | </ul> | |
30 | <h2> | |
31 | <a name="functions_next_prior">Function</a> templates next() and prior()</h2> | |
32 | <p>Certain data types, such as the C++ Standard Library's forward and bidirectional | |
33 | iterators, do not provide addition and subtraction via operator+() or | |
34 | operator-(). This means that non-modifying computation of the next or | |
35 | prior value requires a temporary, even though operator++() or operator--() is | |
36 | provided. It also means that writing code like <code>itr+1</code> inside | |
37 | a template restricts the iterator category to random access iterators.</p> | |
38 | <p>The next() and prior() functions provide a simple way around these problems:</p> | |
39 | <blockquote> | |
40 | <pre>template <class T> | |
41 | T next(T x) { return ++x; } | |
42 | ||
43 | template <class T, class Distance> | |
44 | T next(T x, Distance n) | |
45 | { | |
46 | std::advance(x, n); | |
47 | return x; | |
48 | } | |
49 | ||
50 | template <class T> | |
51 | T prior(T x) { return --x; } | |
52 | ||
53 | template <class T, class Distance> | |
54 | T prior(T x, Distance n) | |
55 | { | |
56 | std::advance(x, -n); | |
57 | return x; | |
58 | }</pre> | |
59 | </blockquote> | |
60 | <p>Usage is simple:</p> | |
61 | <blockquote> | |
62 | <pre>const std::list<T>::iterator p = get_some_iterator(); | |
63 | const std::list<T>::iterator prev = boost::prior(p); | |
64 | const std::list<T>::iterator next = boost::next(prev, 2);</pre> | |
65 | </blockquote> | |
66 | <p>The distance from the given iterator should be supplied as an absolute value. For | |
67 | example, the iterator four iterators prior to the given iterator <code>p</code> | |
68 | may be obtained by <code>prior(p, 4)</code>.</p> | |
69 | <p>Contributed by <a href="http://www.boost.org/people/dave_abrahams.htm">Dave Abrahams</a>. Two-argument versions by Daniel Walker.</p> | |
70 | ||
71 | <h2><a name="result_of">Class template | |
72 | result_of</a></h2> <p>The class template | |
73 | <code>result_of</code> helps determine the type of a | |
74 | call expression. For example, given an lvalue <code>f</code> of | |
75 | type <code>F</code> and lvalues <code>t1</code>, | |
76 | <code>t2</code>, ..., <code>t<em>N</em></code> of | |
77 | types <code>T1</code>, <code>T2</code>, ..., | |
78 | <code>T<em>N</em></code>, respectively, the type | |
79 | <code>result_of<F(T1, T2, ..., | |
80 | T<em>N</em>)>::type</code> defines the result type | |
81 | of the expression <code>f(t1, t2, | |
82 | ...,t<em>N</em>)</code>. This implementation permits | |
83 | the type <code>F</code> to be a function pointer, | |
84 | function reference, member function pointer, or class | |
85 | type. By default, <em>N</em> may be any value between 0 and | |
86 | 16. To change the upper limit, define the macro | |
87 | <code>BOOST_RESULT_OF_NUM_ARGS</code> to the maximum | |
88 | value for <em>N</em>. Class template <code>result_of</code> | |
89 | resides in the header <code><<a | |
90 | href="../../boost/utility/result_of.hpp">boost/utility/result_of.hpp</a>></code>.</p> | |
91 | ||
92 | <p>If your compiler's support for <code>decltype</code> is | |
93 | adequate, <code>result_of</code> automatically uses it to | |
94 | deduce the type of the call expression, in which case | |
95 | <code>result_of<F(T1, T2, ..., | |
96 | T<em>N</em>)>::type</code> names the type | |
97 | <code>decltype(boost::declval<F>()(boost::declval<T1>(), | |
98 | boost::declval<T2>(), ..., | |
99 | boost::declval<T<em>N</em>>()))</code>, as in the | |
100 | following example.</p> | |
101 | ||
102 | <blockquote> | |
103 | <pre>struct functor { | |
104 | template<class T> | |
105 | T operator()(T x) | |
106 | { | |
107 | return x; | |
108 | } | |
109 | }; | |
110 | ||
111 | typedef boost::result_of< | |
112 | functor(int) | |
113 | >::type type; // type is int</pre> | |
114 | </blockquote> | |
115 | ||
116 | <p>You can test whether <code>result_of</code> is using | |
117 | <code>decltype</code> by checking if the macro | |
118 | <code>BOOST_RESULT_OF_USE_DECLTYPE</code> is defined after | |
119 | including <code>result_of.hpp</code>. You can also force | |
120 | <code>result_of</code> to use <code>decltype</code> by | |
121 | defining <code>BOOST_RESULT_OF_USE_DECLTYPE</code> prior | |
122 | to including <code>result_of.hpp</code>.</p> | |
123 | ||
124 | <p>If <code>decltype</code> is not used, | |
125 | then automatic result type deduction of function | |
126 | objects is not possible. Instead, <code>result_of</code> | |
127 | uses the following protocol to allow the programmer to | |
128 | specify a type. When <code>F</code> is a class type with a | |
129 | member type <code>result_type</code>, | |
130 | <code>result_of<F(T1, T2, ..., | |
131 | T<em>N</em>)>::type</code> is | |
132 | <code>F::result_type</code>. When <code>F</code> does | |
133 | not contain <code>result_type</code>, | |
134 | <code>result_of<F(T1, T2, ..., | |
135 | T<em>N</em>)>::type</code> is <code>F::result<F(T1, | |
136 | T2, ..., T<em>N</em>)>::type</code> when | |
137 | <code><em>N</em> > 0</code> or <code>void</code> | |
138 | when <code><em>N</em> = 0</code>. Note that it is the | |
139 | responsibility of the programmer to ensure that | |
140 | function objects accurately advertise their result | |
141 | type via this protocol, as in the following | |
142 | example.</p> | |
143 | ||
144 | <blockquote> | |
145 | <pre>struct functor { | |
146 | template<class> struct result; | |
147 | ||
148 | template<class F, class T> | |
149 | struct result<F(T)> { | |
150 | typedef T type; | |
151 | }; | |
152 | ||
153 | template<class T> | |
154 | T operator()(T x) | |
155 | { | |
156 | return x; | |
157 | } | |
158 | }; | |
159 | ||
160 | typedef boost::result_of< | |
161 | functor(int) | |
162 | >::type type; // type is int</pre> | |
163 | </blockquote> | |
164 | ||
165 | <p>Since <code>decltype</code> is a new language | |
166 | feature recently standardized in C++11, | |
167 | if you are writing a function object | |
168 | to be used with <code>result_of</code>, for | |
169 | maximum portability, you might consider following | |
170 | the above protocol even if your compiler has | |
171 | proper <code>decltype</code> support. If you wish to continue to | |
172 | use the protocol on compilers that | |
173 | support <code>decltype</code>, there are two options: | |
174 | You can use <code>boost::tr1_result_of</code>, which is also | |
175 | defined in <code><<a href="../../boost/utility/result_of.hpp">boost/utility/result_of.hpp</a>></code>. | |
176 | Alternatively, you can define the macro | |
177 | <code>BOOST_RESULT_OF_USE_TR1</code>, which causes | |
178 | <code>result_of</code> to use the protocol described | |
179 | above instead of <code>decltype</code>. If you choose to | |
180 | follow the protocol, take care to ensure that the | |
181 | <code>result_type</code> and | |
182 | <code>result<></code> members accurately | |
183 | represent the return type of | |
184 | <code>operator()</code> given a call expression.</p> | |
185 | ||
186 | <p>Additionally, <code>boost::result_of</code> | |
187 | provides a third mode of operation, which some users | |
188 | may find convenient. When | |
189 | <code>BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK</code> | |
190 | is defined, <code>boost::result_of</code> behaves as | |
191 | follows. If the function object has a member | |
192 | type <code>result_type</code> or member | |
193 | template <code>result<></code>, then | |
194 | <code>boost::result_of</code> will use the TR1 | |
195 | protocol. Otherwise, | |
196 | <code>boost::result_of</code> will | |
197 | use <code>decltype</code>. Using TR1 with | |
198 | a <code>declytpe</code> fallback may workaround | |
199 | certain problems at the cost of portability. For | |
200 | example: | |
201 | <ul> | |
202 | <li>Deficient compiler: If your code | |
203 | requires <code>boost::result_of</code> to work | |
204 | with incomplete return types but your | |
205 | compiler's <code>decltype</code> implementation | |
206 | does not support incomplete return types, then you | |
207 | can use the TR1 protocol as a workaround. Support | |
208 | for incomplete return types was added late in the | |
209 | C++11 standardization process | |
210 | (see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf">N3276</a>) | |
211 | and is not implemented by some compilers.</li> | |
212 | ||
213 | <li>Deficient legacy code: If your existing TR1 | |
214 | function object advertises a different type than | |
215 | the actual result type deduced | |
216 | by <code>decltype</code>, then using TR1 with a | |
217 | <code>decltype</code> fallback will allow you to | |
218 | work with both your existing TR1 function objects | |
219 | and new C++11 function object. This situation | |
220 | could occur if your legacy function objects | |
221 | misused the TR1 protocol. See the documentation on | |
222 | known <a href="#result_of_tr1_diff">differences</a> | |
223 | between <code>boost::result_of</code> and TR1.</li> | |
224 | </ul> | |
225 | ||
226 | <a name="BOOST_NO_RESULT_OF"></a> | |
227 | <p>This implementation of <code>result_of</code> | |
228 | requires class template partial specialization, the | |
229 | ability to parse function types properly, and support | |
230 | for SFINAE. If <code>result_of</code> is not supported | |
231 | by your compiler, including the header | |
232 | <code>boost/utility/result_of.hpp</code> will | |
233 | define the macro <code>BOOST_NO_RESULT_OF</code>.</p> | |
234 | ||
235 | <p>For additional information | |
236 | about <code>result_of</code>, see the C++ Library | |
237 | Technical Report, | |
238 | <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">N1836</a>, | |
239 | or, for motivation and design rationale, | |
240 | the <code>result_of</code> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1454.html">proposal</a>.</p> | |
241 | ||
242 | <a name="result_of_guidelines"> | |
243 | <h3>Usage guidelines for boost::result_of</h3> | |
244 | </a> | |
245 | ||
246 | <p>The following are general suggestions about when | |
247 | and how to use <code>boost::result_of</code>.</p> | |
248 | ||
249 | <ol> | |
250 | <li> If you are targeting C++11 and are not concerned | |
251 | about portability to non-compliant compilers or | |
252 | previous versions of the standard, then use | |
253 | <code>std::result_of</code>. If <code>std::result_of</code> | |
254 | meets your needs, then there's no reason to stop using | |
255 | it.</li> | |
256 | ||
257 | <li> If you are targeting C++11 but may port your code | |
258 | to legacy compilers at some time in the future, then | |
259 | use <code>boost::result_of</code> with | |
260 | <code>decltype</code>. When <code>decltype</code> is | |
261 | used <code>boost::result_of</code> | |
262 | and <code>std::result_of</code> are usually | |
263 | interchangeable. See the documentation on | |
264 | known <a href="#result_of_cxx11_diff">differences</a> | |
265 | between boost::result_of and C++11 result_of.</li> | |
266 | ||
267 | <li> If compiler portability is required, | |
268 | use <code>boost::result_of</code> with the TR1 protocol.</li> | |
269 | </ol> | |
270 | ||
271 | <p>Regardless of how you | |
272 | configure <code>boost::result_of</code>, it is | |
273 | important to bear in mind that the return type of a | |
274 | function may change depending on its arguments, and | |
275 | additionally, the return type of a member function may | |
276 | change depending on the cv-qualification of the | |
277 | object. <code>boost::result_of</code> must be passed | |
278 | the appropriately cv-qualified types in order to | |
279 | deduce the corresponding return type. For example: | |
280 | ||
281 | <blockquote> | |
282 | <pre>struct functor { | |
283 | int& operator()(int); | |
284 | int const& operator()(int) const; | |
285 | ||
286 | float& operator()(float&); | |
287 | float const& operator()(float const&); | |
288 | }; | |
289 | ||
290 | typedef boost::result_of< | |
291 | functor(int) | |
292 | >::type type1; // type1 is int & | |
293 | ||
294 | typedef boost::result_of< | |
295 | const functor(int) | |
296 | >::type type2; // type2 is int const & | |
297 | ||
298 | typedef boost::result_of< | |
299 | functor(float&) | |
300 | >::type type3; // type3 is float & | |
301 | ||
302 | typedef boost::result_of< | |
303 | functor(float const&) | |
304 | >::type type4; // type4 is float const &</pre> | |
305 | </blockquote> | |
306 | ||
307 | <a name="result_of_tr1_protocol_guidelines"> | |
308 | <h3>Usage guidelines for the TR1 result_of protocol</h3> | |
309 | </a> | |
310 | ||
311 | <p>On compliant C++11 | |
312 | compilers, <code>boost::result_of</code> can | |
313 | use <code>decltype</code> to deduce the type of any | |
314 | call expression, including calls to function | |
315 | objects. However, on pre-C++11 compilers or on | |
316 | compilers without adequate decltype support, | |
317 | additional scaffolding is needed from function | |
318 | objects as described above. The following are | |
319 | suggestions about how to use the TR1 protocol.</p> | |
320 | ||
321 | <ul> | |
322 | <li>When the return type does not depend on the | |
323 | argument types or the cv-qualification of the | |
324 | function object, simply | |
325 | define <code>result_type</code>. There is no need | |
326 | to use the <code>result</code> template unless the | |
327 | return type varies.</li> | |
328 | ||
329 | <li>Use the protocol specified type when defining | |
330 | function prototypes. This can help ensure the | |
331 | actual return type does not get out of sync with | |
332 | the protocol specification. For example: | |
333 | ||
334 | <blockquote> | |
335 | <pre>struct functor { | |
336 | typedef int result_type; | |
337 | result_type operator()(int); | |
338 | };</pre> | |
339 | </blockquote> </li> | |
340 | ||
341 | <li>Always specify the <code>result</code> | |
342 | specialization near the corresponding | |
343 | <code>operator()</code> overload. This can make it | |
344 | easier to keep the specializations in sync with the | |
345 | overloads. For example: | |
346 | ||
347 | <blockquote> | |
348 | <pre>struct functor { | |
349 | template<class> struct result; | |
350 | ||
351 | template<class F> | |
352 | struct result<F(int)> { | |
353 | typedef int& type; | |
354 | }; | |
355 | result<functor(int)>::type operator()(int); | |
356 | ||
357 | template<class F> | |
358 | struct result<const F(int)> { | |
359 | typedef int const& type; | |
360 | }; | |
361 | result<const functor(int)>::type operator()(int) const; | |
362 | };</pre> | |
363 | </blockquote> </li> | |
364 | ||
365 | <li>Use type transformations to simplify | |
366 | the <code>result</code> template specialization. For | |
367 | example, the following uses | |
368 | <a href="../type_traits/doc/html/index.html">Boost.TypeTraits</a> | |
369 | to specialize the <code>result</code> template for | |
370 | a single <code>operator()</code> that can be called on | |
371 | both a const and non-const function object with | |
372 | either an lvalue or rvalue argument. | |
373 | ||
374 | <blockquote> | |
375 | <pre>struct functor { | |
376 | template<class> struct result; | |
377 | ||
378 | template<class F, class T> | |
379 | struct result<F(T)> | |
380 | : boost::remove_cv< | |
381 | typename boost::remove_reference<T>::type | |
382 | > | |
383 | {}; | |
384 | ||
385 | template<class T> | |
386 | T operator()(T const& x) const; | |
387 | };</pre> | |
388 | </blockquote></li> | |
389 | </ul> | |
390 | ||
391 | <a name="result_of_tr1_diff"> | |
392 | <h3>Known differences between boost::result_of and TR1 result_of</h3> | |
393 | </a> | |
394 | ||
395 | When using <code>decltype</code>, <code>boost::result_of</code> | |
396 | ignores the TR1 protocol and instead deduces the | |
397 | return type of function objects directly | |
398 | via <code>decltype</code>. In most situations, users | |
399 | will not notice a difference, so long as they use the | |
400 | protocol correctly. The following are situations in | |
401 | which the type deduced | |
402 | by <code>boost::result_of</code> is known to differ depending on | |
403 | whether <code>decltype</code> or the TR1 protocol is | |
404 | used. | |
405 | ||
406 | <ul> | |
407 | <li> TR1 protocol misusage | |
408 | ||
409 | <p>When using the TR1 | |
410 | protocol, <code>boost::result_of</code> cannot | |
411 | detect whether the actual type of a call to a | |
412 | function object is the same as the type specified | |
413 | by the protocol, which allows for the possibility | |
414 | of inadvertent mismatches between the specified | |
415 | type and the actual type. When | |
416 | using <code>decltype</code>, these subtle bugs | |
417 | may result in compilation errors. For example:</p> | |
418 | ||
419 | <blockquote> | |
420 | <pre>struct functor { | |
421 | typedef short result_type; | |
422 | int operator()(short); | |
423 | }; | |
424 | ||
425 | #ifdef BOOST_RESULT_OF_USE_DECLTYPE | |
426 | ||
427 | BOOST_STATIC_ASSERT(( | |
428 | boost::is_same<boost::result_of<functor(short)>::type, int>::value | |
429 | )); | |
430 | ||
431 | #else | |
432 | ||
433 | BOOST_STATIC_ASSERT(( | |
434 | boost::is_same<boost::result_of<functor(short)>::type, short>::value | |
435 | )); | |
436 | ||
437 | #endif</pre> | |
438 | </blockquote> | |
439 | ||
440 | <p>Note that the user can | |
441 | force <code>boost::result_of</code> to use the TR1 | |
442 | protocol even on platforms that | |
443 | support <code>decltype</code> by | |
444 | defining <code>BOOST_RESULT_OF_USE_TR1</code>.</p></li> | |
445 | ||
446 | <li> Nullary function objects | |
447 | ||
448 | <p>When using the TR1 protocol, <code>boost::result_of</code> | |
449 | cannot always deduce the type of calls to | |
450 | nullary function objects, in which case the | |
451 | type defaults to void. When using <code>decltype</code>, | |
452 | <code>boost::result_of</code> always gives the actual type of the | |
453 | call expression. For example:</p> | |
454 | ||
455 | <blockquote> | |
456 | <pre>struct functor { | |
457 | template<class> struct result { | |
458 | typedef int type; | |
459 | }; | |
460 | int operator()(); | |
461 | }; | |
462 | ||
463 | #ifdef BOOST_RESULT_OF_USE_DECLTYPE | |
464 | ||
465 | BOOST_STATIC_ASSERT(( | |
466 | boost::is_same<boost::result_of<functor()>::type, int>::value | |
467 | )); | |
468 | ||
469 | #else | |
470 | ||
471 | BOOST_STATIC_ASSERT(( | |
472 | boost::is_same<boost::result_of<functor()>::type, void>::value | |
473 | )); | |
474 | ||
475 | #endif</pre> | |
476 | </blockquote> | |
477 | ||
478 | <p>Note that there are some workarounds for the | |
479 | nullary function problem. So long as the return | |
480 | type does not vary, | |
481 | <code>result_type</code> can always be used to | |
482 | specify the return type regardless of arity. If the | |
483 | return type does vary, then the user can | |
484 | specialize <code>boost::result_of</code> itself for | |
485 | nullary calls.</p></li> | |
486 | ||
487 | <li> Non-class prvalues and cv-qualification | |
488 | ||
489 | <p>When using the TR1 | |
490 | protocol, <code>boost::result_of</code> will | |
491 | report the cv-qualified type specified | |
492 | by <code>result_type</code> or | |
493 | the <code>result</code> template regardless of | |
494 | the actual cv-qualification of the call | |
495 | expression. When using | |
496 | <code>decltype</code>, <code>boost::result_of</code> | |
497 | will report the actual type of the call expression, | |
498 | which is not cv-qualified when the expression is a | |
499 | non-class prvalue. For example:</p> | |
500 | ||
501 | <blockquote> | |
502 | <pre>struct functor { | |
503 | template<class> struct result; | |
504 | template<class F, class T> struct result<F(const T)> { | |
505 | typedef const T type; | |
506 | }; | |
507 | ||
508 | const short operator()(const short); | |
509 | int const & operator()(int const &); | |
510 | }; | |
511 | ||
512 | // Non-prvalue call expressions work the same with or without decltype. | |
513 | ||
514 | BOOST_STATIC_ASSERT(( | |
515 | boost::is_same< | |
516 | boost::result_of<functor(int const &)>::type, | |
517 | int const & | |
518 | ::value | |
519 | )); | |
520 | ||
521 | // Non-class prvalue call expressions are not actually cv-qualified, | |
522 | // but only the decltype-based result_of reports this accurately. | |
523 | ||
524 | #ifdef BOOST_RESULT_OF_USE_DECLTYPE | |
525 | ||
526 | BOOST_STATIC_ASSERT(( | |
527 | boost::is_same< | |
528 | boost::result_of<functor(const short)>::type, | |
529 | short | |
530 | ::value | |
531 | )); | |
532 | ||
533 | #else | |
534 | ||
535 | BOOST_STATIC_ASSERT(( | |
536 | boost::is_same< | |
537 | boost::result_of<functor(const short)>::type, | |
538 | const short | |
539 | ::value | |
540 | )); | |
541 | ||
542 | #endif</pre> | |
543 | </blockquote></li> | |
544 | </ul> | |
545 | ||
546 | <a name="result_of_cxx11_diff"> | |
547 | <h3>Known differences between boost::result_of and C++11 result_of</h3> | |
548 | </a> | |
549 | ||
550 | <p>When using <code>decltype</code>, <code>boost::result_of</code> | |
551 | implements most of the C++11 result_of | |
552 | specification. One known exception is that | |
553 | <code>boost::result_of</code> does not implement the | |
554 | requirements regarding pointers to member data.</p> | |
555 | ||
556 | <p>Created by Doug Gregor. Contributions from Daniel Walker, Eric Niebler, Michel Morin and others</p> | |
557 | ||
558 | <h2><a name="BOOST_BINARY">Macro BOOST_BINARY</a></h2> | |
559 | ||
560 | <p>The macro <code>BOOST_BINARY</code> is used for the | |
561 | representation of binary literals. It takes as an argument | |
562 | a binary number arranged as an arbitrary amount of 1s and 0s in | |
563 | groupings of length 1 to 8, with groups separated | |
564 | by spaces. The type of the literal yielded is determined by | |
565 | the same rules as those of hex and octal | |
566 | literals (<i>2.13.1p1</i>). By implementation, this macro | |
567 | expands directly to an octal literal during preprocessing, so | |
568 | there is no overhead at runtime and the result is useable in | |
569 | any place that an octal literal would be.</p> | |
570 | ||
571 | <p>In order to directly support binary literals with suffixes, | |
572 | additional macros of the form BOOST_BINARY_XXX are also | |
573 | provided, where XXX is a standard integer suffix in all capital | |
574 | letters. In addition, LL and ULL suffixes may be used for representing | |
575 | long long and unsigned long long types in compilers which provide | |
576 | them as an extension.</p> | |
577 | ||
578 | ||
579 | <p>The BOOST_BINARY family of macros resides in the header | |
580 | <a | |
581 | href="../../boost/utility/binary.hpp"><boost/utility/binary.hpp></a> | |
582 | which is automatically included by | |
583 | <a | |
584 | href="../../boost/utility.hpp"><boost/utility.hpp></a>. | |
585 | ||
586 | <p>Contributed by Matt Calabrese.</p><p> | |
587 | </p><h3>Example</h3> | |
588 | <blockquote> | |
589 | <pre> | |
590 | void foo( int ); | |
591 | ||
592 | void foo( unsigned long ); | |
593 | ||
594 | void bar() | |
595 | { | |
596 | int value1 = BOOST_BINARY( 100 111000 01 1 110 ); | |
597 | ||
598 | unsigned long value2 = BOOST_BINARY_UL( 100 001 ); // unsigned long | |
599 | ||
600 | long long value3 = BOOST_BINARY_LL( 11 000 ); // long long if supported | |
601 | ||
602 | assert( BOOST_BINARY( 10010 ) | |
603 | & BOOST_BINARY( 11000 ) | |
604 | == BOOST_BINARY( 10000 ) | |
605 | ); | |
606 | ||
607 | foo( BOOST_BINARY( 1010 ) ); // calls the first foo | |
608 | ||
609 | foo( BOOST_BINARY_LU( 1010 ) ); // calls the second foo | |
610 | } | |
611 | </pre></blockquote> | |
612 | <hr> | |
613 | <p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan | |
614 | -->04 September, 2008<!--webbot bot="Timestamp" endspan i-checksum="39369" | |
615 | --> | |
616 | </p> | |
617 | <p>© Copyright Beman Dawes 1999-2003.</p> | |
618 | <p>Distributed under the Boost Software License, Version 1.0. See | |
619 | <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a></p> | |
620 | ||
621 | </body> | |
622 | </html> |