123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154 |
- <html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
- <title>Rationale</title>
- <link rel="stylesheet" href="../../../../../doc/src/boostbook.css" type="text/css">
- <meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
- <link rel="home" href="../index.html" title="Chapter 1. Boost.FunctionTypes 2.5">
- <link rel="up" href="../index.html" title="Chapter 1. Boost.FunctionTypes 2.5">
- <link rel="prev" href="reference/macros.html" title="Macros">
- <link rel="next" href="acknowledgements.html" title="Acknowledgements">
- </head>
- <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
- <table cellpadding="2" width="100%"><tr>
- <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../boost.png"></td>
- <td align="center"><a href="../../../../../index.html">Home</a></td>
- <td align="center"><a href="../../../../../libs/libraries.htm">Libraries</a></td>
- <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td>
- <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td>
- <td align="center"><a href="../../../../../more/index.htm">More</a></td>
- </tr></table>
- <hr>
- <div class="spirit-nav">
- <a accesskey="p" href="reference/macros.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../index.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="acknowledgements.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a>
- </div>
- <div class="section">
- <div class="titlepage"><div><div><h2 class="title" style="clear: both">
- <a name="boost_functiontypes.rationale"></a><a class="link" href="rationale.html" title="Rationale">Rationale</a>
- </h2></div></div></div>
- <h4>
- <a name="boost_functiontypes.rationale.h0"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.error_handling_rationale"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.error_handling_rationale">Error handling
- rationale</a>
- </h4>
- <p>
- The library does not define the required members of class templates in case
- of an error. This technique causes the compiler to stop displaying diagnostics
- in client code, at the point where the error actually is, instead of tracing
- template instantiations into the implementation of the library.
- </p>
- <p>
- The library's components have limited error conditions, so problematic input
- can be spotted easily.
- </p>
- <h4>
- <a name="boost_functiontypes.rationale.h1"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.why_mpl_sequences_"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.why_mpl_sequences_">Why
- MPL Sequences?</a>
- </h4>
- <p>
- MPL provides algorithms on Sequences, so transformations (such as turning by-value
- parameter types into const references for optimized forwarding or computing
- a signature to specialize <a href="../../../../function/index.html" target="_top"><code class="literal">boost::function</code></a>
- after applying <a href="../../../../bind/index.html" target="_top"><code class="literal">boost::bind</code></a>)
- can be expressed more easily. The MPL Sequence concept is compatible with several
- other Boost libraries (most importantly <a href="../../../../fusion/index.html" target="_top">Fusion</a>),
- so another reason is interoperability.
- </p>
- <h4>
- <a name="boost_functiontypes.rationale.h2"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.pointer_to_member_object_types"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.pointer_to_member_object_types">Pointer
- to member object types</a>
- </h4>
- <p>
- Despite their syntax, pointer to member object types can be seen as dereferencing
- functionals.
- </p>
- <h4>
- <a name="boost_functiontypes.rationale.h3"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.the_classtransform_template_parameter"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.the_classtransform_template_parameter">The
- ClassTransform template parameter</a>
- </h4>
- <p>
- <code class="literal">This</code>-pointer, <code class="literal">this</code>-reference or just
- the object (or maybe even a smart pointer to the object) plus adjustments of
- cv-qualification - all these cases have their place, somewhere and there is
- no single best answer.
- </p>
- <p>
- Special treatment of the class type within the sequence can significantly complicate
- client code. A custom <code class="literal">ClassTransform</code> argument allows the
- client to adjust the class type before the sequence is formed and then treat
- all parameters uniformly.
- </p>
- <h4>
- <a name="boost_functiontypes.rationale.h4"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.why_tag_types_"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.why_tag_types_">Why
- tag types?</a>
- </h4>
- <p>
- Let's consider the alternatives.
- </p>
- <p>
- The first one is just using more templates so every property has to be asked
- for explicitly. This approach results in more complicated client code if more
- than one propery has to be checked and in a exponentially larger library interface.
- </p>
- <p>
- The second alternative is having the client pass in bit patterns via non-type
- template parameters. The logic has to be performed by the client and there
- are much more error conditions. Further, class templates with non-type template
- parameters do not work within MPL lambda expressions and can cause problems
- with older compilers.
- </p>
- <h4>
- <a name="boost_functiontypes.rationale.h5"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.is_it_safe_to_have_the_synthesis_templates_take_a_callable__builtin_type_or_an_mpl_sequence_as_the_first_template_argument_"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.is_it_safe_to_have_the_synthesis_templates_take_a_callable__builtin_type_or_an_mpl_sequence_as_the_first_template_argument_">Is
- it safe to have the synthesis templates take a callable builtin type or an
- MPL sequence as the first template argument?</a>
- </h4>
- <p>
- Yes, but it isn't immediately obvious as the set of possible MPL sequences
- isn't inherently disjoint from the set of callable builtin types.
- </p>
- <p>
- However, any attempt to make a builtin type work as an MPL sequence is a bad
- idea, because builtin types are accessible before the headers that make the
- type a sequence have been included, which can easily violate the ODR.
- </p>
- <h4>
- <a name="boost_functiontypes.rationale.h6"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.why_does_the_hidden__literal_this__literal__parameter_count_for_the__function_arity_of_member_functions_"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.why_does_the_hidden__literal_this__literal__parameter_count_for_the__function_arity_of_member_functions_">Why
- does the hidden <code class="literal">this</code> parameter count for the function arity
- of member functions?</a>
- </h4>
- <p>
- It was found preferable that the following condition holds:
- </p>
- <pre class="programlisting"><span class="identifier">mpl</span><span class="special">::</span><span class="identifier">size</span><span class="special"><</span> <a class="link" href="reference/decomposition.html#boost_functiontypes.reference.decomposition.parameter_types" title="parameter_types">parameter_types</a><span class="special"><</span><span class="identifier">T</span><span class="special">></span> <span class="special">>::</span><span class="identifier">value</span> <span class="special">==</span> <a class="link" href="reference/decomposition.html#boost_functiontypes.reference.decomposition.function_arity" title="function_arity">function_arity</a><span class="special"><</span><span class="identifier">T</span><span class="special">>::</span><span class="identifier">value</span>
- </pre>
- <h4>
- <a name="boost_functiontypes.rationale.h7"></a>
- <span class="phrase"><a name="boost_functiontypes.rationale.why_ignore_top_level_cv_qualifiers_on_pointers_"></a></span><a class="link" href="rationale.html#boost_functiontypes.rationale.why_ignore_top_level_cv_qualifiers_on_pointers_">Why
- ignore top-level cv-qualifiers on pointers?</a>
- </h4>
- <p>
- A cv-qualified pointer is still a pointer. It usually doesn't matter and even
- if it does, it's a job for <a href="../../../../type_traits/index.html" target="_top">Boost.TypeTraits</a>.
- </p>
- </div>
- <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
- <td align="left"></td>
- <td align="right"><div class="copyright-footer">Copyright © 2004-2007 Tobias
- Schwinger<p>
- Distributed under the Boost Software License, Version 1.0. (See accompanying
- file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
- </p>
- </div></td>
- </tr></table>
- <hr>
- <div class="spirit-nav">
- <a accesskey="p" href="reference/macros.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../index.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="acknowledgements.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a>
- </div>
- </body>
- </html>
|