ceph/src/boost/libs/utility/utility.htm

   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">&lt;boost/utility.hpp&gt;</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-().&nbsp; This means that non-modifying computation of the next or
  35                         prior value requires a temporary, even though operator++() or operator--() is
  36                         provided.&nbsp; 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 &lt;class T&gt;
  41 T next(T x) { return ++x; }
  42
  43 template &lt;class T, class Distance&gt;
  44 T next(T x, Distance n)
  45 {
  46     std::advance(x, n);
  47     return x;
  48 }
  49
  50 template &lt;class T&gt;
  51 T prior(T x) { return --x; }
  52
  53 template &lt;class T, class Distance&gt;
  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&lt;T&gt;::iterator p = get_some_iterator();
  63 const std::list&lt;T&gt;::iterator prev = boost::prior(p);
  64 const std::list&lt;T&gt;::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&lt;F(T1, T2, ...,
  80                 T<em>N</em>)&gt;::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>&lt;<a
  90                 href="../../boost/utility/result_of.hpp">boost/utility/result_of.hpp</a>&gt;</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&lt;F(T1, T2, ...,
  96                 T<em>N</em>)&gt;::type</code> names the type
  97                 <code>decltype(boost::declval&lt;F&gt;()(boost::declval&lt;T1&gt;(),
  98                 boost::declval&lt;T2&gt;(), ...,
  99                 boost::declval&lt;T<em>N</em>&gt;()))</code>, as in the
 100                 following example.</p>
 101
 102                 <blockquote>
 103                 <pre>struct functor {
 104     template&lt;class T&gt;
 105     T operator()(T x)
 106     {
 107         return x;
 108     }
 109 };
 110
 111 typedef boost::result_of&lt;
 112     functor(int)
 113 &gt;::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&lt;F(T1, T2, ...,
 131                 T<em>N</em>)&gt;::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&lt;F(T1, T2, ...,
 135                 T<em>N</em>)&gt;::type</code> is <code>F::result&lt;F(T1,
 136                 T2, ..., T<em>N</em>)&gt;::type</code> when
 137                 <code><em>N</em> &gt; 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&lt;class&gt; struct result;
 147
 148     template&lt;class F, class T&gt;
 149     struct result&lt;F(T)&gt; {
 150         typedef T type;
 151     };
 152
 153     template&lt;class T&gt;
 154     T operator()(T x)
 155     {
 156         return x;
 157     }
 158 };
 159
 160 typedef boost::result_of&lt;
 161     functor(int)
 162 &gt;::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>&lt;<a href="../../boost/utility/result_of.hpp">boost/utility/result_of.hpp</a>&gt;</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&lt;&gt;</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&lt;&gt;</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&lt;
 291     functor(int)
 292 &gt;::type type1; // type1 is int &
 293
 294 typedef boost::result_of&lt;
 295     const functor(int)
 296 &gt;::type type2; // type2 is int const &
 297
 298 typedef boost::result_of&lt;
 299     functor(float&)
 300 &gt;::type type3; // type3 is float &
 301
 302 typedef boost::result_of&lt;
 303     functor(float const&)
 304 &gt;::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&lt;class&gt; struct result;
 350
 351     template&lt;class F&gt;
 352     struct result&lt;F(int)&gt; {
 353         typedef int& type;
 354     };
 355     result&lt;functor(int)&gt;::type operator()(int);
 356
 357     template&lt;class F&gt;
 358     struct result&lt;const F(int)&gt; {
 359         typedef int const& type;
 360     };
 361     result&lt;const functor(int)&gt;::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&lt;class&gt; struct result;
 377
 378     template&lt;class F, class T&gt;
 379     struct result&lt;F(T)&gt;
 380         : boost::remove_cv&lt;
 381               typename boost::remove_reference&lt;T&gt;::type
 382           &gt;
 383     {};
 384
 385     template&lt;class T&gt;
 386     T operator()(T const&amp; 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&lt;boost::result_of&lt;functor(short)&gt;::type, int&gt;::value
 429 ));
 430
 431 #else
 432
 433 BOOST_STATIC_ASSERT((
 434    boost::is_same&lt;boost::result_of&lt;functor(short)&gt;::type, short&gt;::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&lt;class&gt; 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&lt;boost::result_of&lt;functor()&gt;::type, int&gt;::value
 467 ));
 468
 469 #else
 470
 471 BOOST_STATIC_ASSERT((
 472    boost::is_same&lt;boost::result_of&lt;functor()&gt;::type, void&gt;::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&lt;class&gt; struct result;
 504    template&lt;class F, class T&gt; struct result&lt;F(const T)&gt; {
 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&lt;
 516        boost::result_of&lt;functor(int const &)&gt;::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&lt;
 528        boost::result_of&lt;functor(const short)&gt;::type,
 529        short
 530 ::value
 531 ));
 532
 533 #else
 534
 535 BOOST_STATIC_ASSERT((
 536    boost::is_same&lt;
 537        boost::result_of&lt;functor(const short)&gt;::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">&lt;boost/utility/binary.hpp&gt;</a>
 582                 which is automatically included by
 583                 <a
 584                 href="../../boost/utility.hpp">&lt;boost/utility.hpp&gt;</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&nbsp; <!--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>&copy; 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>