<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
-<tr class="field"><th class="field-name">Abstract:</th><td class="field-body">Use this library to write functions and class templates</td>
+<tr class="field"><th class="field-name">Abstract:</th><td class="field-body">Use this library to write functions and class templates that can
+accept arguments by name:</td>
</tr>
</tbody>
</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 15)</p>
-Field list ends without a blank line; unexpected unindent.</div>
-<p>that can accept arguments by name:</p>
<pre class="literal-block">
new_window(
"alert"
parameters whose identity can be deduced from their types.</p>
<!-- @jam_prefix.append('''
project test
- : requirements <include>. <implicit-dependency>/boost//headers ; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 39)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+ : requirements <include>. <implicit-dependency>/boost//headers ;
+''') -->
<!-- @example.prepend('''
#include <boost/parameter.hpp>
};
}
using namespace test;
-int x = -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 83)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''');</p>
+int x =
+'''); -->
<!-- @test('compile') -->
<hr class="docutils" />
<table class="docutils field-list" frame="void" rules="none">
<div class="contents topic" id="table-of-contents">
<p class="topic-title first"><strong>Table of Contents</strong></p>
<ul class="auto-toc simple">
-<li><a class="reference internal" href="#motivation" id="id2
4">1 Motivation</a><ul class="auto-toc">
-<li><a class="reference internal" href="#named-function-parameters" id="id25">1.1 Named Function Parameters</a></li>
-<li><a class="reference internal" href="#deduced-function-parameters" id="id26">1.2 Deduced Function Parameters</a></li>
-<li><a class="reference internal" href="#class-template-parameter-support" id="id27">1.3 Class Template Parameter Support</a></li>
+<li><a class="reference internal" href="#motivation" id="id2
2">1 Motivation</a><ul class="auto-toc">
+<li><a class="reference internal" href="#named-function-parameters" id="id23">1.1 Named Function Parameters</a></li>
+<li><a class="reference internal" href="#deduced-function-parameters" id="id24">1.2 Deduced Function Parameters</a></li>
+<li><a class="reference internal" href="#class-template-parameter-support" id="id25">1.3 Class Template Parameter Support</a></li>
</ul>
</li>
-<li><a class="reference internal" href="#tutorial" id="id2
8">2 Tutorial</a><ul class="auto-toc">
-<li><a class="reference internal" href="#parameter-enabled-functions" id="id29">2.1 Parameter-Enabled Functions</a></li>
-<li><a class="reference internal" href="#parameter-enabled-member-functions" id="id30">2.2 Parameter-Enabled Member Functions</a></li>
-<li><a class="reference internal" href="#parameter-enabled-function-call-operators" id="id31">2.3 Parameter-Enabled Function Call Operators</a></li>
-<li><a class="reference internal" href="#parameter-enabled-constructors" id="id32">2.4 Parameter-Enabled Constructors</a></li>
-<li><a class="reference internal" href="#parameter-enabled-class-templates" id="id33">2.5 Parameter-Enabled Class Templates</a></li>
+<li><a class="reference internal" href="#tutorial" id="id2
6">2 Tutorial</a><ul class="auto-toc">
+<li><a class="reference internal" href="#parameter-enabled-functions" id="id27">2.1 Parameter-Enabled Functions</a></li>
+<li><a class="reference internal" href="#parameter-enabled-member-functions" id="id28">2.2 Parameter-Enabled Member Functions</a></li>
+<li><a class="reference internal" href="#parameter-enabled-function-call-operators" id="id29">2.3 Parameter-Enabled Function Call Operators</a></li>
+<li><a class="reference internal" href="#parameter-enabled-constructors" id="id30">2.4 Parameter-Enabled Constructors</a></li>
+<li><a class="reference internal" href="#parameter-enabled-class-templates" id="id31">2.5 Parameter-Enabled Class Templates</a></li>
</ul>
</li>
-<li><a class="reference internal" href="#advanced-topics" id="id3
4">3 Advanced Topics</a><ul class="auto-toc">
-<li><a class="reference internal" href="#fine-grained-name-control" id="id35">3.1 Fine-Grained Name Control</a></li>
-<li><a class="reference internal" href="#more-argumentpacks" id="id36">3.2 More <span class="concept">ArgumentPack</span>s</a></li>
+<li><a class="reference internal" href="#advanced-topics" id="id3
2">3 Advanced Topics</a><ul class="auto-toc">
+<li><a class="reference internal" href="#fine-grained-name-control" id="id33">3.1 Fine-Grained Name Control</a></li>
+<li><a class="reference internal" href="#more-argumentpacks" id="id34">3.2 More <span class="concept">ArgumentPack</span>s</a></li>
</ul>
</li>
-<li><a class="reference internal" href="#best-practices" id="id3
7">4 Best Practices</a><ul class="auto-toc">
-<li><a class="reference internal" href="#keyword-naming" id="id38">4.1 Keyword Naming</a></li>
-<li><a class="reference internal" href="#namespaces" id="id39">4.2 Namespaces</a></li>
-<li><a class="reference internal" href="#documentation" id="id40">4.3 Documentation</a></li>
+<li><a class="reference internal" href="#best-practices" id="id3
5">4 Best Practices</a><ul class="auto-toc">
+<li><a class="reference internal" href="#keyword-naming" id="id36">4.1 Keyword Naming</a></li>
+<li><a class="reference internal" href="#namespaces" id="id37">4.2 Namespaces</a></li>
+<li><a class="reference internal" href="#documentation" id="id38">4.3 Documentation</a></li>
</ul>
</li>
-<li><a class="reference internal" href="#portability-considerations" id="id41">5 Portability Considerations</a><ul class="auto-toc">
-<li><a class="reference internal" href="#perfect-forwarding-support" id="id42">5.1 Perfect Forwarding Support</a></li>
-<li><a class="reference internal" href="#boost-mp11-support" id="id43">5.2 Boost.MP11 Support</a></li>
-<li><a class="reference internal" href="#no-sfinae-support" id="id44">5.3 No SFINAE Support</a></li>
-<li><a class="reference internal" href="#no-support-for-result-of" id="id45">5.4 No Support for <tt class="docutils literal">result_of</tt></a></li>
-<li><a class="reference internal" href="#can-t-declare-parameterspec-via-typedef" id="id46">5.5 Can't Declare <span class="concept">ParameterSpec</span> via <tt class="docutils literal">typedef</tt></a></li>
-<li><a class="reference internal" href="#default-arguments-unsupported-on-nested-templates" id="id47">5.6 Default Arguments Unsupported on Nested Templates</a></li>
-<li><a class="reference internal" href="#compiler-can-t-see-references-in-unnamed-namespace" id="id48">5.7 Compiler Can't See References In Unnamed Namespace</a></li>
+<li><a class="reference internal" href="#portability-considerations" id="id39">5 Portability Considerations</a><ul class="auto-toc">
+<li><a class="reference internal" href="#perfect-forwarding-support" id="id40">5.1 Perfect Forwarding Support</a></li>
+<li><a class="reference internal" href="#boost-mp11-support" id="id41">5.2 Boost.MP11 Support</a></li>
+<li><a class="reference internal" href="#no-sfinae-support" id="id42">5.3 No SFINAE Support</a></li>
+<li><a class="reference internal" href="#no-support-for-result-of" id="id43">5.4 No Support for <tt class="docutils literal">result_of</tt></a></li>
+<li><a class="reference internal" href="#compiler-can-t-see-references-in-unnamed-namespace" id="id44">5.5 Compiler Can't See References In Unnamed Namespace</a></li>
</ul>
</li>
-<li><a class="reference internal" href="#python-binding" id="id49">6 Python Binding</a></li>
-<li><a class="reference internal" href="#reference" id="id50">7 Reference</a></li>
-<li><a class="reference internal" href="#glossary" id="id51">8 Glossary</a></li>
-<li><a class="reference internal" href="#acknowledgements" id="id52">9 Acknowledgements</a></li>
+<li><a class="reference internal" href="#python-binding" id="id45">6 Python Binding</a></li>
+<li><a class="reference internal" href="#reference" id="id46">7 Reference</a></li>
+<li><a class="reference internal" href="#glossary" id="id47">8 Glossary</a><ul class="auto-toc">
+<li><a class="reference internal" href="#argument-or-actual-argument" id="id48">8.1 Argument (or “actual argument”)</a></li>
+<li><a class="reference internal" href="#parameter-or-formal-parameter" id="id49">8.2 Parameter (or “formal parameter”)</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#acknowledgements" id="id50">9 Acknowledgements</a></li>
</ul>
</div>
<hr class="docutils" />
<div class="section" id="motivation">
-<h1><a class="toc-backref" href="#id24">1 Motivation</a></h1>
+<h1><a class="toc-backref" href="#id22">1 Motivation</a></h1>
<p>In C++, <a class="reference internal" href="#arguments">arguments</a> are normally given meaning by their positions with respect
to a <a class="reference internal" href="#parameter">parameter</a> list: the first argument passed maps onto the first parameter
in a function's definition, and so on. That protocol is fine when there is at
most one parameter with a default value, but when there are even a few useful
defaults, the positional interface becomes burdensome:</p>
<ul>
-<li><div class="first system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 134)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-</li>
-</ul>
-<p>Since an argument's meaning is given by its position, we have to choose an
+<li><div class="first compound">
+<p class="compound-first">Since an argument's meaning is given by its position, we have to choose an
(often arbitrary) order for parameters with default values, making some
combinations of defaults unusable:</p>
-<pre class="literal-block">
+<pre class="compound-middle literal-block">
window* new_window(
char const* name
, <strong>int border_width = default_border_width</strong>
bool const movability = false;
window* w = new_window("alert box", movability);
</pre>
-<p>In the example above we wanted to make an unmoveable window with a default
-<tt class="docutils literal">border_width</tt>, but instead we got a moveable window with a <tt class="docutils literal">border_width</tt>
-of zero. To get the desired effect, we'd need to write:</p>
-<pre class="literal-block">
+<p class="compound-middle">In the example above we wanted to make an unmoveable window with a default
+<tt class="docutils literal">border_width</tt>, but instead we got a moveable window with a
+<tt class="docutils literal">border_width</tt> of zero. To get the desired effect, we'd need to write:</p>
+<pre class="compound-last literal-block">
window* w = new_window(
"alert box", <strong>default_border_width</strong>, movability
);
</pre>
-<ul>
-<li><div class="first system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 162)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
</div>
</li>
-</ul>
-<p>It can become difficult for readers to understand the meaning of arguments at
-the call site:</p>
-<pre class="literal-block">
+<li><div class="first compound">
+<p class="compound-first">It can become difficult for readers to understand the meaning of arguments
+at the call site:</p>
+<pre class="compound-middle literal-block">
window* w = new_window("alert", 1, true, false);
</pre>
-<p>Is this window moveable and initially invisible, or unmoveable and initially
-visible? The reader needs to remember the order of arguments to be sure.</p>
-<ul class="simple">
-<li>The author of the call may not remember the order of the arguments either,</li>
+<p class="compound-last">Is this window moveable and initially invisible, or unmoveable and
+initially visible? The reader needs to remember the order of arguments to
+be sure.</p>
+</div>
+</li>
+<li><p class="first">The author of the call may not remember the order of the arguments either,
+leading to hard-to-find bugs.</p>
+</li>
</ul>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 173)</p>
-Bullet list ends without a blank line; unexpected unindent.</div>
-<p>leading to hard-to-find bugs.</p>
<!-- @ignore(3) -->
<div class="section" id="named-function-parameters">
-<h2><a class="toc-backref" href="#id25">1.1 Named Function Parameters</a></h2>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 181)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>This library addresses the problems outlined above by associating each
+<h2><a class="toc-backref" href="#id23">1.1 Named Function Parameters</a></h2>
+<div class="compound">
+<p class="compound-first">This library addresses the problems outlined above by associating each
parameter name with a keyword object. Now users can identify arguments by
name, rather than by position:</p>
-<pre class="literal-block">
+<pre class="compound-last literal-block">
window* w = new_window(
"alert box"
, <strong>movable_=</strong>false
); // OK!
</pre>
+</div>
<!-- @ignore() -->
</div>
<div class="section" id="deduced-function-parameters">
-<h2><a class="toc-backref" href="#id26">1.2 Deduced Function Parameters</a></h2>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 200)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>A <strong>deduced parameter</strong> can be passed in any position <em>without</em> supplying an
-explicit parameter name. It's not uncommon for a function to have parameters
-that can be uniquely identified based on the types of arguments passed. The
-<tt class="docutils literal">name</tt> parameter to <tt class="docutils literal">new_window</tt> is one such example. None of the other
-arguments, if valid, can reasonably be converted to a <tt class="docutils literal">char const*</tt>. With
-a deduced parameter interface, we could pass the window name in <em>any</em> argument
-position without causing ambiguity:</p>
-<pre class="literal-block">
+<h2><a class="toc-backref" href="#id24">1.2 Deduced Function Parameters</a></h2>
+<div class="compound">
+<p class="compound-first">A <strong>deduced parameter</strong> can be passed in any position <em>without</em> supplying
+an explicit parameter name. It's not uncommon for a function to have
+parameters that can be uniquely identified based on the types of arguments
+passed. The <tt class="docutils literal">name</tt> parameter to <tt class="docutils literal">new_window</tt> is one such
+example. None of the other arguments, if valid, can reasonably be
+converted to a <tt class="docutils literal">char const*</tt>. With a deduced parameter interface, we
+could pass the window name in <em>any</em> argument position without causing
+ambiguity:</p>
+<pre class="compound-middle literal-block">
window* w = new_window(
movable_=false
, <strong>"alert box"</strong>
, movable_=false
); // OK!
</pre>
-<p>Appropriately used, a deduced parameter interface can free the user of the
+<p class="compound-last">Appropriately used, a deduced parameter interface can free the user of the
burden of even remembering the formal parameter names.</p>
+</div>
<!-- @ignore() -->
</div>
<div class="section" id="class-template-parameter-support">
-<h2><a class="toc-backref" href="#id27">1.3 Class Template Parameter Support</a></h2>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 230)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>The reasoning we've given for named and deduced parameter interfaces applies
-equally well to class templates as it does to functions. Using the Parameter
-library, we can create interfaces that allow template arguments (in this case
-<tt class="docutils literal">shared</tt> and <tt class="docutils literal">Client</tt>) to be explicitly named, like this:</p>
-<pre class="literal-block">
+<h2><a class="toc-backref" href="#id25">1.3 Class Template Parameter Support</a></h2>
+<div class="compound">
+<p class="compound-first">The reasoning we've given for named and deduced parameter interfaces
+applies equally well to class templates as it does to functions. Using
+the Parameter library, we can create interfaces that allow template
+arguments (in this case <tt class="docutils literal">shared</tt> and <tt class="docutils literal">Client</tt>) to be explicitly named,
+like this:</p>
+<pre class="compound-middle literal-block">
smart_ptr<
<strong>ownership<shared></strong>
, <strong>value_type<Client></strong>
> p;
</pre>
-<p>The syntax for passing named template arguments is not quite as natural as it
-is for function arguments (ideally, we'd be able to write
-<tt class="docutils literal">smart_ptr<ownership = shared, …></tt>). This small syntactic deficiency makes
-deduced parameters an especially big win when used with class templates:</p>
-<pre class="literal-block">
+<p class="compound-middle">The syntax for passing named template arguments is not quite as natural as
+it is for function arguments (ideally, we'd be able to write
+<tt class="docutils literal">smart_ptr<ownership = shared, …></tt>). This small syntactic deficiency
+makes deduced parameters an especially big win when used with class
+templates:</p>
+<pre class="compound-last literal-block">
// <em>p and q could be equivalent, given a deduced</em>
// <em>parameter interface.</em>
smart_ptr<<strong>shared</strong>, <strong>Client</strong>> p;
smart_ptr<<strong>Client</strong>, <strong>shared</strong>> q;
</pre>
+</div>
<!-- @ignore(2) -->
</div>
</div>
<div class="section" id="tutorial">
-<h1><a class="toc-backref" href="#id28">2 Tutorial</a></h1>
+<h1><a class="toc-backref" href="#id26">2 Tutorial</a></h1>
<p>This tutorial shows all the basics—how to build both named- and
deduced-parameter interfaces to function templates and class
templates—and several more advanced idioms as well.</p>
<div class="section" id="parameter-enabled-functions">
-<h2><a class="toc-backref" href="#id29">2.1 Parameter-Enabled Functions</a></h2>
+<h2><a class="toc-backref" href="#id27">2.1 Parameter-Enabled Functions</a></h2>
<p>In this section we'll show how the Parameter library can be used to
build an expressive interface to the <a class="reference external" href="../../../graph/doc/index.html">Boost Graph library</a>'s
<a class="reference external" href="../../../graph/doc/depth_first_search.html"><tt class="docutils literal">depth_first_search</tt></a> algorithm.<a class="footnote-reference" href="#old-interface" id="id3"><sup>1</sup></a></p>
-<!-- Revisit this -->
-<p>After laying some groundwork and describing the algorithm's abstract
+<!-- Revisit this
+
+After laying some groundwork and describing the algorithm's abstract
interface, we'll show you how to build a basic implementation with keyword
support. Then we'll add support for default arguments and we'll gradually
-refine the implementation with syntax improvements. Finally we'll show how
-to streamline the implementation of named parameter interfaces, improve their
-participation in overload resolution, and optimize their runtime efficiency.</p>
+refine the implementation with syntax improvements. Finally we'll show
+how to streamline the implementation of named parameter interfaces,
+improve their participation in overload resolution, and optimize their
+runtime efficiency. -->
<div class="section" id="headers-and-namespaces">
<h3>2.1.1 Headers And Namespaces</h3>
<p>Most components of the Parameter library are declared in a header named for
say otherwise, you can use the rule above to figure out which header to
<tt class="docutils literal">#include</tt> to access any given component of the library.</p>
<!-- @example.append('''
-using boost::parameter::keyword; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 306)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using boost::parameter::keyword;
+''') -->
<!-- @test('compile') -->
<p>Also, the examples below will also be written as if the namespace alias</p>
<pre class="literal-block">
<!-- @ignore() -->
<p>However, most of the parameters have a useful default value,
as shown in the table below.</p>
-<div class="system-message" id="default-expressions">
-<span id="parameter-table"></span><p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 349)</p>
-<p>Content block expected for the "table" directive; none found.</p>
-<pre class="literal-block">
-.. table:: ``depth_first_search`` Parameters
-
-</pre>
-</div>
-<table border="1" class="docutils">
+<table border="1" class="docutils" id="default-expressions">
+<span id="parameter-table"></span><caption><tt class="docutils literal">depth_first_search</tt> Parameters</caption>
<colgroup>
-<col width="21%" />
-<col width="8%" />
-<col width="34%" />
-<col width="37%" />
+<col width="20%" />
+<col width="7%" />
+<col width="30%" />
+<col width="43%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Parameter
<td>Model of
<a class="reference external" href="../../../graph/doc/IncidenceGraph.html"><span class="concept">Incidence Graph</span></a> and
<a class="reference external" href="../../../graph/doc/VertexListGraph.html"><span class="concept">Vertex List Graph</span></a></td>
-<td>none - this argument is
-required.</td>
+<td>none - this argument is required.</td>
</tr>
<tr><td><tt class="docutils literal">visitor</tt></td>
<td>in</td>
-<td>Model of
-<a class="reference external" href="../../../graph/doc/DFSVisitor.html"><span class="concept">DFS Visitor</span></a></td>
-<td><tt class="docutils literal">boost::</tt>
-<tt class="docutils literal"><span class="pre">dfs_visitor<>()</span></tt></td>
+<td>Model of <a class="reference external" href="../../../graph/doc/DFSVisitor.html"><span class="concept">DFS Visitor</span></a></td>
+<td><tt class="docutils literal"><span class="pre">boost::dfs_visitor<>()</span></tt></td>
</tr>
<tr><td><tt class="docutils literal">root_vertex</tt></td>
<td>in</td>
<td><tt class="docutils literal">graph</tt>'s vertex
descriptor type.</td>
-<td><tt class="docutils literal">*vertices(graph)</tt>
-<tt class="docutils literal">.first</tt></td>
+<td><tt class="docutils literal"><span class="pre">*vertices(graph).first</span></tt></td>
</tr>
<tr><td><tt class="docutils literal">index_map</tt></td>
<td>in</td>
<tt class="docutils literal">graph</tt>'s vertex
descriptor and value
type an integer type.</td>
-<td><dl class="first docutils">
-<dt><tt class="docutils literal">get(</tt></dt>
-<dd><blockquote class="first">
-<tt class="docutils literal">boost::</tt>
-<tt class="docutils literal">vertex_index</tt></blockquote>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 369)</p>
-Block quote ends without a blank line; unexpected unindent.</div>
-<p class="last"><tt class="docutils literal">, graph</tt></p>
-</dd>
-</dl>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 370)</p>
-Definition list ends without a blank line; unexpected unindent.</div>
-<p class="last"><tt class="docutils literal">)</tt></p>
-</td>
+<td><tt class="docutils literal"><span class="pre">get(boost::vertex_index,graph)</span></tt></td>
</tr>
<tr><td><tt class="docutils literal">color_map</tt></td>
<td>in /
with key type :=
<tt class="docutils literal">graph</tt>'s vertex
descriptor type.</td>
-<td>a <tt class="docutils literal">boost::</tt>
-<tt class="docutils literal">iterator_property_map</tt>
-created from a
-<tt class="docutils literal"><span class="pre">std::vector</span></tt> of
-<tt class="docutils literal">default_color_type</tt>
-of size
-<tt class="docutils literal">num_vertices(graph)</tt>
-and using <tt class="docutils literal">index_map</tt>
-for the index map.</td>
+<td>a <tt class="docutils literal"><span class="pre">boost::iterator_property_map</span></tt>
+created from a <tt class="docutils literal"><span class="pre">std::vector</span></tt> of
+<tt class="docutils literal">default_color_type</tt> of size
+<tt class="docutils literal">num_vertices(graph)</tt> and using
+<tt class="docutils literal">index_map</tt> for the index map.</td>
</tr>
</tbody>
</table>
<tt class="docutils literal">my_color_map</tt> argument. In this step we'll create one such
<strong>keyword object</strong> for each parameter. Each keyword object will be
identified by a unique <strong>keyword tag type</strong>.</p>
-<!-- Revisit this -->
-<p>We're going to define our interface in namespace <tt class="docutils literal">graphs</tt>. Since users need
-access to the keyword objects, but not the tag types, we'll define the keyword
-objects so they're accessible through <tt class="docutils literal">graphs</tt>, and we'll hide the tag types
-away in a nested namespace, <tt class="docutils literal"><span class="pre">graphs::tag</span></tt>. The library provides a
-convenient macro for that purpose.</p>
+<!-- Revisit this
+
+We're going to define our interface in namespace ``graphs``. Since users
+need access to the keyword objects, but not the tag types, we'll define
+the keyword objects so they're accessible through ``graphs``, and we'll
+hide the tag types away in a nested namespace, ``graphs::tag``. The
+library provides a convenient macro for that purpose. -->
<p>We're going to define our interface in namespace <tt class="docutils literal">graphs</tt>. The
library provides a convenient macro for defining keyword objects:</p>
<pre class="literal-block">
BOOST_PARAMETER_FUNCTION(
(void), // 1. parenthesized return type
depth_first_search, // 2. name of the function template
-
tag, // 3. namespace of tag types
-
- (required (graph, \*) ) // 4. one required parameter, and
-
+ (required (graph, *) ) // 4. one required parameter, and
(optional // four optional parameters,
// with defaults
- (visitor, \*, boost::dfs_visitor<>())
- (root_vertex, \*, \*vertices(graph).first)
- (index_map, \*, get(boost::vertex_index,graph))
- (color_map, \*,
+ (visitor, *, boost::dfs_visitor<>())
+ (root_vertex, *, *vertices(graph).first)
+ (index_map, *, get(boost::vertex_index,graph))
+ (color_map, *,
default_color_map(num_vertices(graph), index_map)
)
)
};
int vertex_index = 0;
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 527)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('compile') -->
<p>The arguments to <tt class="docutils literal">BOOST_PARAMETER_FUNCTION</tt> are:</p>
-<p>1. The return type of the resulting function template. Parentheses around
+<ol class="arabic simple">
+<li>The return type of the resulting function template. Parentheses around
the return type prevent any commas it might contain from confusing the
-preprocessor, and are always required.</p>
-<ol class="arabic simple" start="2">
+preprocessor, and are always required.</li>
<li>The name of the resulting function template.</li>
-</ol>
-<p>3. The name of a namespace where we can find tag types whose names match the
-function's parameter names.</p>
-<ol class="arabic simple" start="4">
+<li>The name of a namespace where we can find tag types whose names match the
+function's parameter names.</li>
<li>The function signature.</li>
</ol>
</div>
when all the parameters are optional.</p>
<div class="section" id="required-parameters">
<h4>2.1.5.1 Required Parameters</h4>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 559)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>Required parameters are given first—nested in a <tt class="docutils literal">(required … )</tt> clause—as a
-series of two-element tuples describing each parameter name and any
-requirements on the argument type. In this case there is only a single
-required parameter, so there's just a single tuple:</p>
-<pre class="literal-block">
+<div class="compound">
+<p class="compound-first">Required parameters are given first—nested in a <tt class="docutils literal">(required … )</tt>
+clause—as a series of two-element tuples describing each parameter name
+and any requirements on the argument type. In this case there is only a
+single required parameter, so there's just a single tuple:</p>
+<pre class="compound-middle literal-block">
(required <strong>(graph, *)</strong> )
</pre>
-<p>Since <tt class="docutils literal">depth_first_search</tt> doesn't require any particular type for
-its <tt class="docutils literal">graph</tt> parameter, we use an asterix to indicate that any type is
-allowed. Required parameters must always precede any optional parameters in
-a signature, but if there are <em>no</em> required parameters, the <tt class="docutils literal">(required … )</tt>
-clause can be omitted entirely.</p>
+<p class="compound-last">Since <tt class="docutils literal">depth_first_search</tt> doesn't require any particular type for its
+<tt class="docutils literal">graph</tt> parameter, we use an asterix to indicate that any type is
+allowed. Required parameters must always precede any optional parameters
+in a signature, but if there are <em>no</em> required parameters, the
+<tt class="docutils literal">(required … )</tt> clause can be omitted entirely.</p>
+</div>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
BOOST_PARAMETER_NAME(graph)
-BOOST_PARAMETER_FUNCTION((void), f, tag, -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 582)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+BOOST_PARAMETER_FUNCTION((void), f, tag,
+''') -->
<!-- @example.append(') {}') -->
<!-- @test('compile') -->
</div>
<div class="section" id="optional-parameters">
<h4>2.1.5.2 Optional Parameters</h4>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 590)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>Optional parameters—nested in an <tt class="docutils literal">(optional … )</tt> clause—are given as a
-series of adjacent <em>three</em>-element tuples describing the parameter name, any
-requirements on the argument type, <em>and</em> and an expression representing the
-parameter's default value:</p>
-<pre class="literal-block">
+<div class="compound">
+<p class="compound-first">Optional parameters—nested in an <tt class="docutils literal">(optional … )</tt> clause—are given as a
+series of adjacent <em>three</em>-element tuples describing the parameter name,
+any requirements on the argument type, <em>and</em> and an expression
+representing the parameter's default value:</p>
+<pre class="compound-last literal-block">
(optional
<strong>(visitor, *, boost::dfs_visitor<>())
(root_vertex, *, *vertices(graph).first)
)</strong>
)
</pre>
+</div>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
BOOST_PARAMETER_NAME(in_out(color_map))
BOOST_PARAMETER_FUNCTION((void), f, tag,
- (required (graph, \*)) -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 629)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+ (required (graph, \*))
+''') -->
<!-- @example.append(') {}') -->
<!-- @test('compile') -->
</div>
<div class="section" id="handling-in-out-consume-move-from-and-forward-parameters">
<h4>2.1.5.3 Handling “In”, “Out”, “Consume / Move-From”, and “Forward” Parameters</h4>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 637)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>By default, Boost.Parameter treats all parameters as if they were <em>forward</em>
-<a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would take in by rvalue reference and only
-<tt class="docutils literal"><span class="pre">std::forward</span></tt> or <tt class="docutils literal"><span class="pre">boost::forward</span></tt> to other functions. Such parameters
-can be <tt class="docutils literal">const</tt> lvalues, mutable lvalues, <tt class="docutils literal">const</tt> rvalues, or mutable
-rvalues. Therefore, the default configuration grants the most flexibility to
-user code. However:</p>
-<p>*. Users can configure one or more parameters to be <em>in</em> <a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which
-can fall into the same categories as <em>forward</em> <a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a> but are now
-passed by <tt class="docutils literal">const</tt> lvalue reference and so must only be read from. Continuing
-from the previous example, to indicate that <tt class="docutils literal">root_vertex</tt> and <tt class="docutils literal">index_map</tt>
-are read-only, we wrap their names in <tt class="docutils literal"><span class="pre">in(…)</span></tt>.</p>
-<p>*. Users can configure one or more parameters to be either <em>out</em>
+<div class="compound">
+<p class="compound-first">By default, Boost.Parameter treats all parameters as if they were
+<em>forward</em> <a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would take in by rvalue reference
+and only <tt class="docutils literal"><span class="pre">std::forward</span></tt> or <tt class="docutils literal"><span class="pre">boost::forward</span></tt> to other functions. Such
+parameters can be <tt class="docutils literal">const</tt> lvalues, mutable lvalues, <tt class="docutils literal">const</tt> rvalues,
+or mutable rvalues. Therefore, the default configuration grants the most
+flexibility to user code. However:</p>
+<ul class="compound-middle simple">
+<li>Users can configure one or more parameters to be <em>in</em> <a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>,
+which can fall into the same categories as <em>forward</em> <a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a> but
+are now passed by <tt class="docutils literal">const</tt> lvalue reference and so must only be read
+from. Continuing from the previous example, to indicate that
+<tt class="docutils literal">root_vertex</tt> and <tt class="docutils literal">index_map</tt> are read-only, we wrap their names
+in <tt class="docutils literal"><span class="pre">in(…)</span></tt>.</li>
+<li>Users can configure one or more parameters to be either <em>out</em>
<a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would strictly write to, or <em>in-out</em>
-<a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would both read from and write to. Such
-parameters can only be mutable lvalues. In the example, to indicate that
-<tt class="docutils literal">color_map</tt> is read-write, we wrap its name in <tt class="docutils literal"><span class="pre">in_out(…)</span></tt>. Note that
-Boost.Parameter sees no functional difference between <tt class="docutils literal"><span class="pre">out(…)</span></tt> and
-<tt class="docutils literal"><span class="pre">in_out(…)</span></tt>, so you may choose whichever makes your interfaces more
-self-documenting.</p>
-<p>*. Users can configure one or more parameters to be <em>consume</em> or <em>move-from</em>
-<a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would take in by mutable rvalue reference and
-<tt class="docutils literal"><span class="pre">std::move</span></tt> or <tt class="docutils literal"><span class="pre">boost::move</span></tt> as the last access step. Such parameters can
-only be mutable rvalues. Boost.Parameter supports wrapping the corresponding
-names in <tt class="docutils literal"><span class="pre">consume(…)</span></tt> or <tt class="docutils literal"><span class="pre">move_from(…)</span></tt>.</p>
-<pre class="literal-block">
+<a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would both read from and write
+to. Such parameters can only be mutable lvalues. In the example, to
+indicate that <tt class="docutils literal">color_map</tt> is read-write, we wrap its name in
+<tt class="docutils literal"><span class="pre">in_out(…)</span></tt>. Note that Boost.Parameter sees no functional
+difference between <tt class="docutils literal"><span class="pre">out(…)</span></tt> and <tt class="docutils literal"><span class="pre">in_out(…)</span></tt>, so you may choose
+whichever makes your interfaces more self-documenting.</li>
+<li>Users can configure one or more parameters to be <em>consume</em> or
+<em>move-from</em> <a class="reference external" href="http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters">parameters</a>, which functions would take in by mutable
+rvalue reference and <tt class="docutils literal"><span class="pre">std::move</span></tt> or <tt class="docutils literal"><span class="pre">boost::move</span></tt> as the last
+access step. Such parameters can only be mutable
+rvalues. Boost.Parameter supports wrapping the corresponding names in
+<tt class="docutils literal"><span class="pre">consume(…)</span></tt> or <tt class="docutils literal"><span class="pre">move_from(…)</span></tt>.</li>
+</ul>
+<pre class="compound-middle literal-block">
BOOST_PARAMETER_NAME(graph)
BOOST_PARAMETER_NAME(visitor)
BOOST_PARAMETER_NAME(<strong>in(root_vertex)</strong>)
BOOST_PARAMETER_NAME(<strong>in(index_map)</strong>)
BOOST_PARAMETER_NAME(<strong>in_out(color_map)</strong>)
</pre>
-<p>In order to see what happens when parameters are bound to arguments that
-violate their category constraints, attempt to compile the <a class="reference external" href="../../test/compose.cpp">compose.cpp</a> test
-program with either the <tt class="docutils literal">LIBS_PARAMETER_TEST_COMPILE_FAILURE_0</tt> macro or the
-<tt class="docutils literal">LIBS_PARAMETER_TEST_COMPILE_FAILURE_1</tt> macro <tt class="docutils literal">#defined</tt>. You should
-encounter a compiler error caused by a specific constraint violation.</p>
+<p class="compound-last">In order to see what happens when parameters are bound to arguments that
+violate their category constraints, attempt to compile the <a class="reference external" href="../../test/compose.cpp">compose.cpp</a>
+test program with either the <tt class="docutils literal">LIBS_PARAMETER_TEST_COMPILE_FAILURE_0</tt>
+macro or the <tt class="docutils literal">LIBS_PARAMETER_TEST_COMPILE_FAILURE_1</tt> macro
+<tt class="docutils literal">#defined</tt>. You should encounter a compiler error caused by a specific
+constraint violation.</p>
+</div>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
struct dfs_visitor
{
};
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 693)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @example.append('''
BOOST_PARAMETER_FUNCTION((void), f, tag,
(required (graph, \*))
)
)
{
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 709)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('compile') -->
</div>
<div class="section" id="positional-arguments">
</div>
<div class="section" id="default-expression-evaluation">
<h4>2.1.5.5 Default Expression Evaluation</h4>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 734)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>Note that in our example, the value of the graph parameter is used in the
+<div class="compound">
+<p class="compound-first">Note that in our example, the value of the graph parameter is used in the
default expressions for <tt class="docutils literal">root_vertex</tt>, <tt class="docutils literal">index_map</tt>, and <tt class="docutils literal">color_map</tt>.</p>
-<pre class="literal-block">
+<pre class="compound-last literal-block">
(required (<strong>graph</strong>, *) )
(optional
(visitor, *, boost::dfs_visitor<>())
)
)
</pre>
-<!-- @ignore() -->
-<p>A default expression is evaluated in the context of all preceding parameters,
-so you can use any of their values by name.</p>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 756)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
</div>
-<p>A default expression is never evaluated—or even instantiated—if an actual
-argument is passed for that parameter. We can actually demonstrate that with
-our code so far by replacing the body of <tt class="docutils literal">depth_first_search</tt> with something
-that prints the arguments:</p>
-<pre class="literal-block">
+<!-- @ignore()
+
+A default expression is evaluated in the context of all preceding
+parameters, so you can use any of their values by name. -->
+<div class="compound">
+<p class="compound-first">A default expression is never evaluated—or even instantiated—if an actual
+argument is passed for that parameter. We can actually demonstrate that
+with our code so far by replacing the body of <tt class="docutils literal">depth_first_search</tt> with
+something that prints the arguments:</p>
+<pre class="compound-middle literal-block">
#include <boost/graph/depth_first_search.hpp> // for dfs_visitor
BOOST_PARAMETER_FUNCTION(
return boost::report_errors();
}
</pre>
-<p>Despite the fact that default expressions such as <tt class="docutils literal"><span class="pre">vertices(graph).first</span></tt>
-are ill-formed for the given <tt class="docutils literal">graph</tt> arguments, both calls will compile,
-and each one will print exactly the same thing.</p>
+<p class="compound-last">Despite the fact that default expressions such as
+<tt class="docutils literal"><span class="pre">vertices(graph).first</span></tt> are ill-formed for the given <tt class="docutils literal">graph</tt>
+arguments, both calls will compile, and each one will print exactly the
+same thing.</p>
+</div>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
#include <iostream>
BOOST_PARAMETER_NAME(visitor)
BOOST_PARAMETER_NAME(root_vertex)
BOOST_PARAMETER_NAME(index_map)
-BOOST_PARAMETER_NAME(color_map) -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 811)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+BOOST_PARAMETER_NAME(color_map)
+''') -->
<!-- @example.replace_emphasis('''
, (required
(graph, \*)
(root_vertex, \*)
(index_map, \*)
(color_map, \*)
- ) -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 821)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')
-.. @test('run')</p>
+ )
+ ''') -->
+<!-- @test('run') -->
</div>
<div class="section" id="signature-matching-and-overloading">
<h4>2.1.5.6 Signature Matching and Overloading</h4>
requirements imposed by the implementation of <tt class="docutils literal">depth_first_search</tt>, a
compilation error will occur later, when its body is instantiated.</p>
<p>There are at least three problems with very general function signatures.</p>
-<p>1. By the time our <tt class="docutils literal">depth_first_search</tt> is instantiated, it has been
+<ol class="arabic simple">
+<li>By the time our <tt class="docutils literal">depth_first_search</tt> is instantiated, it has been
selected as the best matching overload. Some other <tt class="docutils literal">depth_first_search</tt>
overload might've worked had it been chosen instead. By the time we see a
-compilation error, there's no chance to change that decision.</p>
-<p>2. Even if there are no overloads, error messages generated at instantiation
-time usually expose users to confusing implementation details. For example,
-users might see references to names generated by <tt class="docutils literal">BOOST_PARAMETER_FUNCTION</tt>
-such as <tt class="docutils literal"><span class="pre">graphs::detail::depth_first_search_with_named_params</span></tt> (or
-worse—think of the kinds of errors you get from your STL implementation when
-you make a mistake).<a class="footnote-reference" href="#conceptsts" id="id7"><sup>4</sup></a></p>
-<p>3. The problems with exposing such permissive function template signatures
+compilation error, there's no chance to change that decision.</li>
+<li>Even if there are no overloads, error messages generated at instantiation
+time usually expose users to confusing implementation details. For
+example, users might see references to names generated by
+<tt class="docutils literal">BOOST_PARAMETER_FUNCTION</tt> such as
+<tt class="docutils literal"><span class="pre">graphs::detail::depth_first_search_with_named_params</span></tt> (or worse—think
+of the kinds of errors you get from your STL implementation when you make
+a mistake).<a class="footnote-reference" href="#conceptsts" id="id7"><sup>4</sup></a></li>
+<li>The problems with exposing such permissive function template signatures
have been the subject of much discussion, especially in the presence of
<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">unqualified calls</a>. If all we want is to avoid unintentional
-argument-dependent lookup (ADL), we can isolate <tt class="docutils literal">depth_first_search</tt> in a
-namespace containing no types<a class="footnote-reference" href="#using" id="id8"><sup>6</sup></a>, but suppose we <em>want</em> it to found
-via ADL?</p>
+argument-dependent lookup (ADL), we can isolate <tt class="docutils literal">depth_first_search</tt> in
+a namespace containing no types<a class="footnote-reference" href="#using" id="id8"><sup>6</sup></a>, but suppose we <em>want</em> it to
+found via ADL?</li>
+</ol>
<p>It's usually a good idea to prevent functions from being considered for
overload resolution when the passed argument types aren't appropriate. The
library already does this when the required <tt class="docutils literal">graph</tt> parameter is not
supplied, but we're not likely to see a depth first search that doesn't take a
graph to operate on. Suppose, instead, that we found a different depth first
search algorithm that could work on graphs that don't model
-<a class="reference external" href="../../../graph/doc/IncidenceGraph.html"><span class="concept">Incidence Graph</span></a>? If we just added a simple overload, it would be ambiguous:</p>
+<a class="reference external" href="../../../graph/doc/IncidenceGraph.html"><span class="concept">Incidence Graph</span></a>? If we just added a simple overload, it would be
+ambiguous:</p>
<pre class="literal-block">
// new overload
BOOST_PARAMETER_FUNCTION((void), depth_first_search, (tag),
>::type
>::vertex_descriptor
>
- , boost::mpl::<a href="#id53"><span class="problematic" id="id54">true_</span></a>
- , boost::mpl::<a href="#id55"><span class="problematic" id="id56">false_</span></a>
+ , boost::mpl::true_
+ , boost::mpl::false_
>
{
};
typename boost::graph_traits<T>::traversal_category
, boost::vertex_list_graph_tag
>
- , boost::mpl::<a href="#id57"><span class="problematic" id="id58">true_</span></a>
- , boost::mpl::<a href="#id59"><span class="problematic" id="id60">false_</span></a>
+ , boost::mpl::true_
+ , boost::mpl::false_
>
>
{
>::type
>::vertex_descriptor
>
- , boost::mpl::<a href="#id61"><span class="problematic" id="id62">true_</span></a>
- , boost::mpl::<a href="#id63"><span class="problematic" id="id64">false_</span></a>
+ , boost::mpl::true_
+ , boost::mpl::false_
>
>
{
>::type
>::vertex_descriptor
>
- , boost::mpl::<a href="#id65"><span class="problematic" id="id66">true_</span></a>
- , boost::mpl::<a href="#id67"><span class="problematic" id="id68">false_</span></a>
+ , boost::mpl::true_
+ , boost::mpl::false_
>
{
};
BOOST_PARAMETER_NAME((_visitor, graphs) visitor)
BOOST_PARAMETER_NAME((_root_vertex, graphs) in(root_vertex))
BOOST_PARAMETER_NAME((_index_map, graphs) in(index_map))
-BOOST_PARAMETER_NAME((_color_map, graphs) in_out(color_map)) -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1097)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+BOOST_PARAMETER_NAME((_color_map, graphs) in_out(color_map))
+''') -->
<!-- @example.append('''
{
}
depth_first_search(g);
depth_first_search(g, _root_vertex = static_cast<int>(x));
return boost::report_errors();
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1124)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('run') -->
<p>It usually isn't necessary to so completely encode the type requirements on
arguments to generic functions. However, doing so is worth the effort: your
enclose that type in parentheses, then <em>replace</em> the <tt class="docutils literal">*</tt> element of the
parameter signature:</p>
<pre class="literal-block">
-BOOST_PARAMETER_NAME((<a href="#id69"><span class="problematic" id="id70">name_</span></a>, keywords) name)
-BOOST_PARAMETER_NAME((<a href="#id71"><span class="problematic" id="id72">movable_</span></a>, keywords) movable)
+BOOST_PARAMETER_NAME((name_, keywords) name)
+BOOST_PARAMETER_NAME((movable_, keywords) movable)
BOOST_PARAMETER_FUNCTION((window*), new_window, keywords,
(deduced
, *(
boost::mpl::eval_if<
boost::is_convertible<boost::mpl::_,char const*>
- , boost::mpl::<a href="#id73"><span class="problematic" id="id74">false_</span></a>
+ , boost::mpl::false_
, boost::mpl::if_<
// see<a class="footnote-reference" href="#is-keyword-expression" id="id14"><sup>5</sup></a>
is_keyword_expression<boost::mpl::_>
- , boost::mpl::<a href="#id75"><span class="problematic" id="id76">false_</span></a>
- , boost::mpl::<a href="#id77"><span class="problematic" id="id78">true_</span></a>
+ , boost::mpl::false_
+ , boost::mpl::true_
>
>
)
#include <boost/mpl/placeholders.hpp>
#include <boost/mpl/if.hpp>
#include <boost/mpl/eval_if.hpp>
-#include <boost/type_traits/is_convertible.hpp> -->
-<p>''')</p>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1321)</p>
-<p>Content block expected for the "Admonition" directive; none found.</p>
-<pre class="literal-block">
-.. Admonition:: Syntax Note
+#include <boost/type_traits/is_convertible.hpp>
-</pre>
-</div>
-<p>A <tt class="docutils literal">(deduced …)</tt> clause always contains a <tt class="docutils literal">(required …)</tt> and/or an
+''') -->
+<div class="admonition-syntax-note admonition">
+<p class="first admonition-title">Syntax Note</p>
+<p class="last">A <tt class="docutils literal">(deduced …)</tt> clause always contains a <tt class="docutils literal">(required …)</tt> and/or an
<tt class="docutils literal">(optional …)</tt> subclause, and must follow any <tt class="docutils literal">(required …)</tt> or
-<tt class="docutils literal">(optional …)</tt> clauses indicating nondeduced parameters at the outer level.</p>
+<tt class="docutils literal">(optional …)</tt> clauses indicating nondeduced parameters at the outer
+level.</p>
+</div>
<p>With the declaration above, the following two calls are equivalent:</p>
<pre class="literal-block">
char const* f_name = "f";
</pre>
<!-- @example.prepend('''
int main()
-{ -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1348)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+{
+''') -->
<p>If the user wants to pass a <tt class="docutils literal">policies</tt> argument that was also, for some
reason, convertible to <tt class="docutils literal">char const*</tt>, she can always specify the parameter
name explicitly, as follows:</p>
(typename parameter::value_type<Args,tag::y>::type), return_y, tag,
(deduced
(required
- (x, (std::map<char const\*,std::string>))
- (y, (char const\*))
+ (x, (std::map<char const*,std::string>))
+ (y, (char const*))
)
(optional
(z, (int), 4)
<p>Then using <tt class="docutils literal">return_y</tt> in any manner other than with positional arguments
will result in a compiler error:</p>
<pre class="literal-block">
-std::map<char const\*,std::string> k2s;
+std::map<char const*,std::string> k2s;
assert("foo" == return_y(2, k2s, "foo")); // error!
</pre>
<!-- @ignore() -->
</div>
</div>
<div class="section" id="parameter-enabled-member-functions">
-<h2><a class="toc-backref" href="#id30">2.2 Parameter-Enabled Member Functions</a></h2>
+<h2><a class="toc-backref" href="#id28">2.2 Parameter-Enabled Member Functions</a></h2>
<p>The <tt class="docutils literal">BOOST_PARAMETER_MEMBER_FUNCTION</tt> and
<tt class="docutils literal">BOOST_PARAMETER_CONST_MEMBER_FUNCTION</tt> macros accept exactly the same
arguments as <tt class="docutils literal">BOOST_PARAMETER_FUNCTION</tt>, but are designed to be used within
<!-- @example.prepend('''
#include <boost/parameter.hpp>
#include <iostream>
-using namespace boost::parameter; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1496)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using namespace boost::parameter;
+''') -->
<!-- @test('run') -->
<p>These macros don't directly allow a function's interface to be separated from
its implementation, but you can always forward arguments on to a separate
BOOST_PARAMETER_NAME(arg1)
BOOST_PARAMETER_NAME(arg2)
-using namespace boost::parameter; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1523)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using namespace boost::parameter;
+''') -->
<!-- @test('compile') -->
<div class="section" id="static-member-functions">
<h3>2.2.1 Static Member Functions</h3>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
#include <iostream>
-using namespace boost::parameter; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1560)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using namespace boost::parameter;
+''') -->
<!-- @test('run') -->
</div>
</div>
<div class="section" id="parameter-enabled-function-call-operators">
-<h2><a class="toc-backref" href="#id31">2.3 Parameter-Enabled Function Call Operators</a></h2>
+<h2><a class="toc-backref" href="#id29">2.3 Parameter-Enabled Function Call Operators</a></h2>
<p>The <tt class="docutils literal">BOOST_PARAMETER_FUNCTION_CALL_OPERATOR</tt> and
<tt class="docutils literal">BOOST_PARAMETER_CONST_FUNCTION_CALL_OPERATOR</tt> macros accept the same
arguments as the <tt class="docutils literal">BOOST_PARAMETER_MEMBER_FUNCTION</tt> and
<!-- @example.prepend('''
#include <boost/parameter.hpp>
#include <iostream>
-using namespace boost::parameter; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1603)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using namespace boost::parameter;
+''') -->
<!-- @test('run') -->
</div>
<div class="section" id="parameter-enabled-constructors">
-<h2><a class="toc-backref" href="#id32">2.4 Parameter-Enabled Constructors</a></h2>
+<h2><a class="toc-backref" href="#id30">2.4 Parameter-Enabled Constructors</a></h2>
<p>The lack of a “delegating constructor” feature in C++
(<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf</a>)
limits somewhat the quality of interface this library can provide
</pre>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
-#include <iostream> -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1642)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+#include <iostream>
+''') -->
<p>Note that the bitwise or (“<tt class="docutils literal">|</tt>”) operator has a special meaning when
applied to keyword objects that are passed to an <span class="concept">ArgumentPack</span>'s indexing
operator: it is used to indicate a default value. In this case if there is no
<!-- @example.wrap('''
#include <boost/core/lightweight_test.hpp>
-int main() { -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1670)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''', ' return boost::report_errors(); }')
-.. @test('run', howmany='all')</p>
+int main() {
+''', ' return boost::report_errors(); }') -->
+<!-- @test('run', howmany='all') -->
<p>For more on <span class="concept">ArgumentPack</span> manipulation, see the <a class="reference internal" href="#advanced-topics">Advanced Topics</a> section.</p>
</div>
<div class="section" id="parameter-enabled-class-templates">
-<h2><a class="toc-backref" href="#id33">2.5 Parameter-Enabled Class Templates</a></h2>
+<h2><a class="toc-backref" href="#id31">2.5 Parameter-Enabled Class Templates</a></h2>
<p>In this section we'll use Boost.Parameter to build <a class="reference external" href="../../../python/doc/index.html">Boost.Python</a>'s <a class="reference external" href="http://www.boost.org/libs/python/doc/v2/class.html#class_-spec">class_</a> template, whose “signature” is:</p>
<pre class="literal-block">
template <
struct bases
{
};
-}} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1836)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}}
+''') -->
</div>
<div class="section" id="argument-packs-and-parameter-extraction">
<span id="binding-intro"></span><h4>2.5.1.4 Argument Packs and Parameter Extraction</h4>
</div>
<div class="section" id="exercising-the-code-so-far">
<h3>2.5.2 Exercising the Code So Far</h3>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1895)</p>
-<p>Content block expected for the "compound" directive; none found.</p>
-<pre class="literal-block">
-.. compound::
-
-</pre>
-</div>
-<p>Revisiting our original examples,</p>
-<pre class="literal-block">
+<div class="compound">
+<p class="compound-first">Revisiting our original examples,</p>
+<pre class="compound-middle literal-block">
typedef boost::python::class_<
class_type<B>, copyable<boost::noncopyable>
> c1;
struct D
{
-}; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1923)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
-<p>we can now examine the intended parameters:</p>
-<pre class="literal-block">
+};
+''') -->
+<p class="compound-middle">we can now examine the intended parameters:</p>
+<pre class="compound-last literal-block">
BOOST_MPL_ASSERT((boost::is_same<c1::class_type, B>));
BOOST_MPL_ASSERT((boost::is_same<c1::base_list, bases<> >));
BOOST_MPL_ASSERT((boost::is_same<c1::held_type, B>));
));
BOOST_MPL_ASSERT((boost::is_same<c2::copyable, void>));
</pre>
+</div>
<!-- @test('compile', howmany='all') -->
</div>
<div class="section" id="deduced-template-parameters">
BOOST_PARAMETER_TEMPLATE_KEYWORD(base_list)
BOOST_PARAMETER_TEMPLATE_KEYWORD(held_type)
BOOST_PARAMETER_TEMPLATE_KEYWORD(copyable)
-}} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1990)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}}
+''') -->
<p>Now we can rewrite our signature to make all three optional parameters
deducible:</p>
<pre class="literal-block">
</pre>
<!-- @example.prepend('''
#include <boost/type_traits/is_class.hpp>
-namespace boost { namespace python { -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2023)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+namespace boost { namespace python {
+''') -->
<!-- @example.append('''
template <
typename A0
args, tag::copyable, void
>::type copyable;
};
-}} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2057)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}}
+''') -->
<p>It may seem like we've added a great deal of complexity, but the benefits to
our users are greater. Our original examples can now be written without
explicit parameter names:</p>
{
};
-using boost::python::bases; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2081)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using boost::python::bases;
+''') -->
<!-- @example.append('''
BOOST_MPL_ASSERT((boost::is_same<c1::class_type, B>));
BOOST_MPL_ASSERT((boost::is_same<c1::base_list, bases<> >));
BOOST_MPL_ASSERT((
boost::is_same<c2::held_type, std::auto_ptr<D> >
));
-BOOST_MPL_ASSERT((boost::is_same<c2::copyable, void>)); -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2097)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+BOOST_MPL_ASSERT((boost::is_same<c2::copyable, void>));
+''') -->
<!-- @test('compile', howmany='all') -->
</div>
</div>
</div>
<div class="section" id="advanced-topics">
-<h1><a class="toc-backref" href="#id34">3 Advanced Topics</a></h1>
+<h1><a class="toc-backref" href="#id32">3 Advanced Topics</a></h1>
<p>At this point, you should have a good grasp of the basics. In this section
we'll cover some more esoteric uses of the library.</p>
<div class="section" id="fine-grained-name-control">
-<h2><a class="toc-backref" href="#id35">3.1 Fine-Grained Name Control</a></h2>
+<h2><a class="toc-backref" href="#id33">3.1 Fine-Grained Name Control</a></h2>
<p>If you don't like the leading-underscore naming convention used to refer to
keyword objects, or you need the name <tt class="docutils literal">tag</tt> for something other than the
keyword type namespace, there's another way to use <tt class="docutils literal">BOOST_PARAMETER_NAME</tt>:</p>
int main()
{
return 0;
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2153)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')
-.. @test('run')</p>
+}
+''') -->
+<!-- @test('run') -->
<p>Before you use this more verbose form, however, please read the section on
<a class="reference internal" href="#keyword-naming">best practices for keyword object naming</a>.</p>
</div>
<div class="section" id="more-argumentpacks">
-<h2><a class="toc-backref" href="#id36">3.2 More <span class="concept">ArgumentPack</span>s</a></h2>
+<h2><a class="toc-backref" href="#id34">3.2 More <span class="concept">ArgumentPack</span>s</a></h2>
<p>We've already seen <span class="concept">ArgumentPack</span>s when we looked at
<a class="reference internal" href="#parameter-enabled-constructors">parameter-enabled constructors</a> and <a class="reference internal" href="#binding-intro">class templates</a>. As you
might have guessed, <span class="concept">ArgumentPack</span>s actually lie at the heart of
</pre>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
-#include <iostream> -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2193)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+#include <iostream>
+''') -->
<p>Also, <span class="concept">ArgumentPack</span>s can be composed using the comma operator. The extra
parentheses below are used to prevent the compiler from seeing two separate
arguments to <tt class="docutils literal">print_name_and_index</tt>:</p>
using parameter::required;
using parameter::optional;
using boost::is_convertible;
-using boost::mpl::_; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2244)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+using boost::mpl::_;
+''') -->
<!-- @example.append('''
int main()
{
return 0;
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2251)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('run', howmany='all') -->
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2255)</p>
-Duplicate substitution definition name: "compose_cpp".</div>
</div>
<div class="section" id="extracting-parameter-types">
<h3>3.2.2 Extracting Parameter Types</h3>
}
</pre>
<!-- @example.prepend('''
-#include <boost/parameter.hpp> -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2286)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+#include <boost/parameter.hpp>
+''') -->
<!-- @example.append('''
#include <boost/core/lightweight_test.hpp>
BOOST_TEST_EQ(a1, 42);
BOOST_TEST_EQ(a2, 3);
return boost::report_errors();
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2299)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('run') -->
<p>Occasionally one needs to deduce argument types without an extra layer of
function call. For example, suppose we wanted to return twice the value of
return 2 * args[_index | 42];
}
</pre>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2316)</p>
-Literal block ends without a blank line; unexpected unindent.</div>
<!-- @example.prepend('''
-#include <boost/parameter.hpp> -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2318)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+#include <boost/parameter.hpp>
+''') -->
<!-- @example.append('''
#include <boost/core/lightweight_test.hpp>
int six = twice_index(_index = 3);
BOOST_TEST_EQ(six, 6);
return boost::report_errors();
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2329)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('run', howmany='all') -->
<p>Note that if we had used <tt class="docutils literal">binding< … ></tt> rather than <tt class="docutils literal">value_type< … ></tt>, we
would end up returning a reference to the temporary created in the <tt class="docutils literal">2 * …</tt>
#include <boost/parameter.hpp>
#include <string>
-namespace parameter = boost::parameter; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2371)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+namespace parameter = boost::parameter;
+''') -->
<!-- @example.append('''
int main()
{
return 0;
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2378)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('run') -->
<p>In the example above, the string <tt class="docutils literal">"hello, world"</tt> is constructed despite the
fact that the user passed us a value for <tt class="docutils literal">s3</tt>. To remedy that, we can
<!-- with a function object built by the Boost Lambda_ library: [#bind]_ -->
<pre class="literal-block">
typename parameter::binding<
- ArgumentPack, <a class="reference external" href="tag::s3">tag::s3</a>, std::string
+ ArgumentPack,tag::s3,std::string
>::type s3 = args[
_s3 <strong>|| boost::bind(
std::plus<std::string>(), boost::ref(s1), boost::ref(s2)
std::string f(ArgumentPack const& args)
{
std::string const& s1 = args[_s1];
- std::string const& s2 = args[_s2]; -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2422)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+ std::string const& s2 = args[_s2];
+''') -->
<!-- @example.append('''
return s3;
}
int main()
{
return 0;
-} -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2434)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+}
+''') -->
<!-- @test('run') -->
<!-- .. _Lambda: ../../../lambda/index.html -->
<div class="sidebar">
</div>
</div>
<div class="section" id="best-practices">
-<h1><a class="toc-backref" href="#id37">4 Best Practices</a></h1>
+<h1><a class="toc-backref" href="#id35">4 Best Practices</a></h1>
<p>By now you should have a fairly good idea of how to use the Parameter
library. This section points out a few more-marginal issues that will help
you use the library more effectively.</p>
<div class="section" id="keyword-naming">
-<h2><a class="toc-backref" href="#id38">4.1 Keyword Naming</a></h2>
+<h2><a class="toc-backref" href="#id36">4.1 Keyword Naming</a></h2>
<p><tt class="docutils literal">BOOST_PARAMETER_NAME</tt> prepends a leading underscore to the names of all our
keyword objects in order to avoid the following usually-silent bug:</p>
<pre class="literal-block">
unnamed namespace.</p>
</div>
<div class="section" id="namespaces">
-<h2><a class="toc-backref" href="#id39">4.2 Namespaces</a></h2>
+<h2><a class="toc-backref" href="#id37">4.2 Namespaces</a></h2>
<p>In our examples we've always declared keyword objects in (an unnamed namespace
within) the same namespace as the Boost.Parameter-enabled functions using
those keywords:</p>
</pre>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
-#include <iostream> -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2562)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')
-.. @namespace_setup = str(example)
-.. @ignore()</p>
+#include <iostream>
+''') -->
+<!-- @namespace_setup = str(example) -->
+<!-- @ignore() -->
<p>Users of these functions have a few choices:</p>
-<ol class="arabic simple">
-<li>Full qualification:</li>
-</ol>
+<ol class="arabic">
+<li><p class="first">Full qualification:</p>
<pre class="literal-block">
int x = <strong>lib::</strong>f(
<strong>lib::</strong>_name = "jill"
);
</pre>
<p>This approach is more verbose than many users would like.</p>
+</li>
+</ol>
<!-- @example.prepend(namespace_setup) -->
<!-- @example.append('int main() { return 0; }') -->
<!-- @test('run') -->
-<ol class="arabic simple" start="2">
-<li>Make keyword objects available through <em>using-declarations</em>:</li>
-</ol>
+<ol class="arabic" start="2">
+<li><p class="first">Make keyword objects available through <em>using-declarations</em>:</p>
<pre class="literal-block">
<strong>using lib::_name;
using lib::_index;</strong>
</pre>
<p>This version is much better at the actual call site, but the
<em>using-declarations</em> themselves can be verbose and hard to manage.</p>
+</li>
+</ol>
<!-- @example.prepend(namespace_setup) -->
<!-- @example.append('int main() { return 0; }') -->
<!-- @test('run') -->
-<ol class="arabic simple" start="3">
-<li>Bring in the entire namespace with a <em>using-directive</em>:</li>
-</ol>
+<ol class="arabic" start="3">
+<li><p class="first">Bring in the entire namespace with a <em>using-directive</em>:</p>
<pre class="literal-block">
<strong>using namespace lib;</strong>
int x = <strong>f</strong>(_name = "jill", _index = 3);
</pre>
-<p>This option is convenient, but it indiscriminately makes the <em>entire</em> contents
-of <tt class="docutils literal">lib</tt> available without qualification.</p>
+<p>This option is convenient, but it indiscriminately makes the <em>entire</em>
+contents of <tt class="docutils literal">lib</tt> available without qualification.</p>
+</li>
+</ol>
<!-- @example.prepend(namespace_setup) -->
<!-- @example.append('int main() { return 0; }') -->
<!-- @test('run') -->
</pre>
<!-- @example.prepend('''
#include <boost/parameter.hpp>
-#include <iostream> -->
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2639)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>''')</p>
+#include <iostream>
+''') -->
<p>Now users need only a single <em>using-directive</em> to bring in just the names of
all keywords associated with <tt class="docutils literal">lib</tt>:</p>
<pre class="literal-block">
<!-- @test('run', howmany='all') -->
</div>
<div class="section" id="documentation">
-<h2><a class="toc-backref" href="#id40">4.3 Documentation</a></h2>
+<h2><a class="toc-backref" href="#id38">4.3 Documentation</a></h2>
<p>The interface idioms enabled by Boost.Parameter are completely new (to C++),
and as such are not served by pre-existing documentation conventions.</p>
<div class="note">
<p class="first admonition-title">Note</p>
-<p class="last">This space is empty because we haven't settled on any best practices</p>
+<p class="last">This space is empty because we haven't settled on any best practices
+yet. We'd be very pleased to link to your documentation if you've got a
+style that you think is worth sharing.</p>
</div>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2660)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>yet. We'd be very pleased to link to your documentation if you've got a style
-that you think is worth sharing.</p>
</div>
</div>
<div class="section" id="portability-considerations">
-<h1><a class="toc-backref" href="#id41">5 Portability Considerations</a></h1>
+<h1><a class="toc-backref" href="#id39">5 Portability Considerations</a></h1>
<p>Use the <a class="reference external" href="http://www.boost.org/regression/release/user/parameter.html">regression test results</a> for the latest Boost release of
the Parameter library to see how it fares on your favorite
compiler. Additionally, you may need to be aware of the following
issues and workarounds for particular compilers.</p>
<div class="section" id="perfect-forwarding-support">
-<h2><a class="toc-backref" href="#id42">5.1 Perfect Forwarding Support</a></h2>
+<h2><a class="toc-backref" href="#id40">5.1 Perfect Forwarding Support</a></h2>
<p>If your compiler supports <a class="reference external" href="http://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html">perfect forwarding</a>, then the Parameter library
will <tt class="docutils literal">#define</tt> the macro <tt class="docutils literal">BOOST_PARAMETER_HAS_PERFECT_FORWARDING</tt> unless
you disable it manually. If your compiler does not provide this support, then
<tt class="docutils literal"><span class="pre">parameter::parameters::operator()</span></tt> will treat rvalue references as lvalue
<tt class="docutils literal">const</tt> references to work around the <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm">forwarding problem</a>, so in certain
-cases you must wrap <a class="reference external" href="../../../core/doc/html/core/ref.html"><tt class="docutils literal"><span class="pre">boost\:\:ref</span></tt></a> or <a class="reference external" href="http://en.cppreference.com/w/cpp/utility/functional/ref"><tt class="docutils literal"><span class="pre">std\:\:ref</span></tt></a> around any arguments that will
+cases you must wrap <a class="reference external" href="../../../core/doc/html/core/ref.html"><tt class="docutils literal"><span class="pre">boost::ref</span></tt></a> or <a class="reference external" href="http://en.cppreference.com/w/cpp/utility/functional/ref"><tt class="docutils literal"><span class="pre">std::ref</span></tt></a> around any arguments that will
be bound to out parameters. The <a class="reference external" href="../../test/evaluate_category.cpp">evaluate_category.cpp</a> and
<a class="reference external" href="../../test/preprocessor_eval_category.cpp">preprocessor_eval_category.cpp</a> test programs demonstrate this support.</p>
</div>
<div class="section" id="boost-mp11-support">
-<h2><a class="toc-backref" href="#id43">5.2 Boost.MP11 Support</a></h2>
+<h2><a class="toc-backref" href="#id41">5.2 Boost.MP11 Support</a></h2>
<p>If your compiler is sufficiently compliant with the C++11 standard, then the
Parameter library will <tt class="docutils literal">#define</tt> the macro <tt class="docutils literal">BOOST_PARAMETER_CAN_USE_MP11</tt>
unless you disable it manually. The <a class="reference external" href="../../test/singular.cpp">singular.cpp</a>, <a class="reference external" href="../../test/compose.cpp">compose.cpp</a>,
<a class="reference external" href="../../test/optional_deduced_sfinae.cpp">optional_deduced_sfinae.cpp</a>, and <a class="reference external" href="../../test/deduced_dependent_predicate.cpp">deduced_dependent_predicate.cpp</a> test programs
demonstrate support for <a class="reference external" href="../../../mp11/doc/html/mp11.html">Boost.MP11</a>.</p>
-<div class="system-message">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2711)</p>
-Duplicate substitution definition name: "compose_cpp".</div>
</div>
<div class="section" id="no-sfinae-support">
-<h2><a class="toc-backref" href="#id44">5.3 No SFINAE Support</a></h2>
+<h2><a class="toc-backref" href="#id42">5.3 No SFINAE Support</a></h2>
<p>Some older compilers don't support SFINAE. If your compiler meets that
criterion, then Boost headers will <tt class="docutils literal">#define</tt> the preprocessor symbol
<tt class="docutils literal">BOOST_NO_SFINAE</tt>, and parameter-enabled functions won't be removed
function as a default generator on those compilers, you'll need to wrap it in
a class that provides <tt class="docutils literal">result_type</tt> as a <tt class="docutils literal">typedef</tt> and invokes the
function via its <tt class="docutils literal">operator()</tt>.</p>
-</div>
-<div class="section" id="can-t-declare-parameterspec-via-typedef">
-<h2><a class="toc-backref" href="#id46">5.5 Can't Declare <span class="concept">ParameterSpec</span> via <tt class="docutils literal">typedef</tt></a></h2>
-<p>In principle you can declare a <span class="concept">ParameterSpec</span> as a <tt class="docutils literal">typedef</tt> for a
-specialization of <tt class="docutils literal"><span class="pre">parameters<…></span></tt>, but Microsoft Visual C++ 6.x has been
-seen to choke on that usage. The workaround is to use inheritance and declare
-your <span class="concept">ParameterSpec</span> as a class:</p>
-<pre class="literal-block">
-<strong>struct dfs_parameters
- :</strong> parameter::parameters<
- <a class="reference external" href="tag::graph">tag::graph</a>, <a class="reference external" href="tag::visitor">tag::visitor</a>, <a class="reference external" href="tag::root_vertex">tag::root_vertex</a>
- , <a class="reference external" href="tag::index_map">tag::index_map</a>, <a class="reference external" href="tag::color_map">tag::color_map</a>
- >
-<strong>{
-};</strong>
-</pre>
-</div>
-<div class="section" id="default-arguments-unsupported-on-nested-templates">
-<h2><a class="toc-backref" href="#id47">5.6 Default Arguments Unsupported on Nested Templates</a></h2>
-<p>As of this writing, Borland compilers don't support the use of default
-template arguments on member class templates. As a result, you have to supply
-<tt class="docutils literal">BOOST_PARAMETER_MAX_ARITY</tt> arguments to every use of
-<tt class="docutils literal"><span class="pre">parameters<…>::match</span></tt>. Since the actual defaults used are unspecified, the
-workaround is to use <a href="#id79"><span class="problematic" id="id80">|BOOST_PARAMETER_MATCH|_</span></a> to declare default arguments for
-SFINAE.</p>
+<!-- Can't Declare |ParameterSpec| via ``typedef``
+=============================================
+
+In principle you can declare a |ParameterSpec| as a ``typedef`` for a
+specialization of ``parameters<…>``, but Microsoft Visual C++ 6.x has been
+seen to choke on that usage. The workaround is to use inheritance and
+declare your |ParameterSpec| as a class:
+
+.. parsed-literal::
+
+ **struct dfs_parameters
+ :** parameter::parameters<
+ tag::graph, tag::visitor, tag::root_vertex
+ , tag::index_map, tag::color_map
+ >
+ **{
+ };**
+
+Default Arguments Unsupported on Nested Templates
+=============================================
+
+As of this writing, Borland compilers don't support the use of default
+template arguments on member class templates. As a result, you have to
+supply ``BOOST_PARAMETER_MAX_ARITY`` arguments to every use of
+``parameters<…>::match``. Since the actual defaults used are unspecified,
+the workaround is to use |BOOST_PARAMETER_MATCH|_ to declare default
+arguments for SFINAE.
+
+.. |BOOST_PARAMETER_MATCH| replace:: ``BOOST_PARAMETER_MATCH`` -->
</div>
<div class="section" id="compiler-can-t-see-references-in-unnamed-namespace">
-<h2><a class="toc-backref" href="#id48">5.7 Compiler Can't See References In Unnamed Namespace</a></h2>
+<h2><a class="toc-backref" href="#id44">5.5 Compiler Can't See References In Unnamed Namespace</a></h2>
<p>If you use Microsoft Visual C++ 6.x, you may find that the compiler has
trouble finding your keyword objects. This problem has been observed, but
only on this one compiler, and it disappeared as the test code evolved, so
</div>
</div>
<div class="section" id="python-binding">
-<h1><a class="toc-backref" href="#id49">6 Python Binding</a></h1>
+<h1><a class="toc-backref" href="#id45">6 Python Binding</a></h1>
<p>Follow <a class="reference external" href="../../../parameter_python/doc/html/index.html">this link</a> for documentation on how to expose
Boost.Parameter-enabled functions to Python with <a class="reference external" href="../../../python/doc/index.html">Boost.Python</a>.</p>
</div>
<div class="section" id="reference">
-<h1><a class="toc-backref" href="#id50">7 Reference</a></h1>
+<h1><a class="toc-backref" href="#id46">7 Reference</a></h1>
<p>Follow <a class="reference external" href="reference.html">this link</a> to the Boost.Parameter reference documentation.</p>
</div>
<div class="section" id="glossary">
-<h1><a class="toc-backref" href="#id51">8 Glossary</a></h1>
-<table class="docutils field-list" frame="void" id="arguments" rules="none">
-<col class="field-name" />
-<col class="field-body" />
-<tbody valign="top">
-<tr class="field"><th class="field-name" colspan="2">Argument (or “actual argument”):</th></tr>
-<tr class="field"><td> </td><td class="field-body">the value actually passed to a function or</td>
-</tr>
-</tbody>
-</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2831)</p>
-Field list ends without a blank line; unexpected unindent.</div>
-<p>class template</p>
-<table class="docutils field-list" frame="void" id="parameter" rules="none">
-<col class="field-name" />
-<col class="field-body" />
-<tbody valign="top">
-<tr class="field"><th class="field-name" colspan="2">Parameter (or “formal parameter”):</th></tr>
-<tr class="field"><td> </td><td class="field-body">the name used to refer to an argument</td>
-</tr>
-</tbody>
-</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2836)</p>
-Field list ends without a blank line; unexpected unindent.</div>
-<p>within a function or class template. For example, the value of <tt class="docutils literal">f</tt>'s
-<em>parameter</em> <tt class="docutils literal">x</tt> is given by the <em>argument</em> <tt class="docutils literal">3</tt>:</p>
+<h1><a class="toc-backref" href="#id47">8 Glossary</a></h1>
+<div class="section" id="argument-or-actual-argument">
+<span id="arguments"></span><h2><a class="toc-backref" href="#id48">8.1 Argument (or “actual argument”)</a></h2>
+<p>the value actually passed to a function or class template.</p>
+</div>
+<div class="section" id="parameter-or-formal-parameter">
+<span id="parameter"></span><h2><a class="toc-backref" href="#id49">8.2 Parameter (or “formal parameter”)</a></h2>
+<p>the name used to refer to an argument within a function or class
+template. For example, the value of <tt class="docutils literal">f</tt>'s <em>parameter</em> <tt class="docutils literal">x</tt> is given by the
+<em>argument</em> <tt class="docutils literal">3</tt>:</p>
<pre class="literal-block">
int f(int x) { return x + 1; }
int y = f(3);
</pre>
</div>
+</div>
<div class="section" id="acknowledgements">
-<h1><a class="toc-backref" href="#id52">9 Acknowledgements</a></h1>
+<h1><a class="toc-backref" href="#id50">9 Acknowledgements</a></h1>
<p>The authors would like to thank all the Boosters who participated in the
review of this library and its documentation, most especially our review
manager, Doug Gregor.</p>
<table class="docutils footnote" frame="void" id="old-interface" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id3">[1]</a></td><td>As of Boost 1.33.0 the Graph library was still using an</td></tr>
+<tr><td class="label"><a class="fn-backref" href="#id3">[1]</a></td><td>As of Boost 1.33.0 the Graph library was still using an
+<a class="reference external" href="../../../graph/doc/bgl_named_params.html">older named parameter mechanism</a>, but there are plans to change it to
+use Boost.Parameter (this library) in an upcoming release, while keeping
+the old interface available for backward-compatibility.</td></tr>
</tbody>
</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2853)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p><a class="reference external" href="../../../graph/doc/bgl_named_params.html">older named parameter mechanism</a>, but there are plans to change it to use
-Boost.Parameter (this library) in an upcoming release, while keeping the old
-interface available for backward-compatibility.</p>
<table class="docutils footnote" frame="void" id="odr" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id5">[2]</a></td><td>The <strong>One Definition Rule</strong> says that any given entity in a C++</td></tr>
+<tr><td class="label"><a class="fn-backref" href="#id5">[2]</a></td><td>The <strong>One Definition Rule</strong> says that any given entity in a C++
+program must have the same definition in all translation units (object
+files) that make up a program.</td></tr>
</tbody>
</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2860)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>program must have the same definition in all translation units (object files)
-that make up a program.</p>
<table class="docutils footnote" frame="void" id="vertex-descriptor" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label">[3]</td><td>If you're not familiar with the Boost Graph Library,</td></tr>
+<tr><td class="label">[3]</td><td>If you're not familiar with the Boost Graph Library,
+don't worry about the meaning of any Graph-library-specific details you
+encounter. In this case you could replace all mentions of vertex
+descriptor types with <tt class="docutils literal">int</tt> in the text, and your understanding of the
+Parameter library wouldn't suffer.</td></tr>
</tbody>
</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2864)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>don't worry about the meaning of any Graph-library-specific details you
-encounter. In this case you could replace all mentions of vertex descriptor
-types with <tt class="docutils literal">int</tt> in the text, and your understanding of the Parameter
-library wouldn't suffer.</p>
<table class="docutils footnote" frame="void" id="conceptsts" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<table class="docutils footnote" frame="void" id="is-keyword-expression" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label">[5]</td><td><em>(<a class="fn-backref" href="#id13">1</a>, <a class="fn-backref" href="#id14">2</a>)</em> Here we're assuming there's a predicate</td></tr>
+<tr><td class="label">[5]</td><td><em>(<a class="fn-backref" href="#id13">1</a>, <a class="fn-backref" href="#id14">2</a>)</em> Here we're assuming there's a predicate
+metafunction <tt class="docutils literal">is_keyword_expression</tt> that can be used to identify
+models of Boost.Python's KeywordExpression concept.</td></tr>
</tbody>
</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2880)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>metafunction <tt class="docutils literal">is_keyword_expression</tt> that can be used to identify
-models of Boost.Python's KeywordExpression concept.</p>
<!-- .. __ http://www.boost.org/regression/release/user/lambda.html -->
<table class="docutils footnote" frame="void" id="using" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id8">[6]</a></td><td>You can always give the illusion that the function</td></tr>
-</tbody>
-</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2888)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>lives in an outer namespace by applying a <em>using-declaration</em>:</p>
+<tr><td class="label"><a class="fn-backref" href="#id8">[6]</a></td><td><p class="first">You can always give the illusion that the function
+lives in an outer namespace by applying a <em>using-declaration</em>:</p>
<pre class="literal-block">
namespace foo_overloads {
}
using foo_overloads::foo;
</pre>
-<p>This technique for avoiding unintentional argument-dependent lookup is due to
-Herb Sutter.</p>
+<p class="last">This technique for avoiding unintentional argument-dependent lookup is due
+to Herb Sutter.</p>
+</td></tr>
+</tbody>
+</table>
<table class="docutils footnote" frame="void" id="sfinae" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label">[7]</td><td>This capability depends on your compiler's support for</td></tr>
+<tr><td class="label">[7]</td><td>This capability depends on your compiler's support for
+SFINAE. <strong>SFINAE</strong>: <strong>S</strong>ubstitution <strong>F</strong>ailure <strong>I</strong>s <strong>N</strong>ot
+<strong>A</strong>n <strong>E</strong>rror. If type substitution during the instantiation of a
+function template results in an invalid type, no compilation error is
+emitted; instead the overload is removed from the overload set. By
+producing an invalid type in the function signature depending on the
+result of some condition, we can decide whether or not an overload is
+considered during overload resolution. The technique is formalized in the
+<a class="reference external" href="../../../core/doc/html/core/enable_if.html"><tt class="docutils literal">enable_if</tt></a> utility. Most recent compilers support SFINAE; on compilers
+that don't support it, the Boost config library will <tt class="docutils literal">#define</tt> the
+symbol <tt class="docutils literal">BOOST_NO_SFINAE</tt>. See
+<a class="reference external" href="http://www.semantics.org/once_weakly/w02_SFINAE.pdf">http://www.semantics.org/once_weakly/w02_SFINAE.pdf</a> for more information
+on SFINAE.</td></tr>
</tbody>
</table>
-<div class="system-message">
-<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2902)</p>
-Explicit markup ends without a blank line; unexpected unindent.</div>
-<p>SFINAE. <strong>SFINAE</strong>: <strong>S</strong>ubstitution <strong>F</strong>ailure <strong>I</strong>s <strong>N</strong>ot
-<strong>A</strong>n <strong>E</strong>rror. If type substitution during the instantiation of a
-function template results in an invalid type, no compilation error is emitted;
-instead the overload is removed from the overload set. By producing an
-invalid type in the function signature depending on the result of some
-condition, we can decide whether or not an overload is considered during
-overload resolution. The technique is formalized in the <a class="reference external" href="../../../core/doc/html/core/enable_if.html"><tt class="docutils literal">enable_if</tt></a>
-utility. Most recent compilers support SFINAE; on compilers that don't
-support it, the Boost config library will <tt class="docutils literal">#define</tt> the symbol
-<tt class="docutils literal">BOOST_NO_SFINAE</tt>. See
-<a class="reference external" href="http://www.semantics.org/once_weakly/w02_SFINAE.pdf">http://www.semantics.org/once_weakly/w02_SFINAE.pdf</a> for more information on
-SFINAE.</p>
-</div>
-<div class="system-messages section">
-<h1>Docutils System Messages</h1>
-<div class="system-message" id="id53">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 896); <em><a href="#id54">backlink</a></em></p>
-Unknown target name: "true".</div>
-<div class="system-message" id="id55">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 896); <em><a href="#id56">backlink</a></em></p>
-Unknown target name: "false".</div>
-<div class="system-message" id="id57">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 956); <em><a href="#id58">backlink</a></em></p>
-Unknown target name: "true".</div>
-<div class="system-message" id="id59">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 956); <em><a href="#id60">backlink</a></em></p>
-Unknown target name: "false".</div>
-<div class="system-message" id="id61">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 956); <em><a href="#id62">backlink</a></em></p>
-Unknown target name: "true".</div>
-<div class="system-message" id="id63">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 956); <em><a href="#id64">backlink</a></em></p>
-Unknown target name: "false".</div>
-<div class="system-message" id="id65">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 956); <em><a href="#id66">backlink</a></em></p>
-Unknown target name: "true".</div>
-<div class="system-message" id="id67">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 956); <em><a href="#id68">backlink</a></em></p>
-Unknown target name: "false".</div>
-<div class="system-message" id="id69">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1163); <em><a href="#id70">backlink</a></em></p>
-Unknown target name: "name".</div>
-<div class="system-message" id="id71">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1163); <em><a href="#id72">backlink</a></em></p>
-Unknown target name: "movable".</div>
-<div class="system-message" id="id73">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1230); <em><a href="#id74">backlink</a></em></p>
-Unknown target name: "false".</div>
-<div class="system-message" id="id75">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1230); <em><a href="#id76">backlink</a></em></p>
-Unknown target name: "false".</div>
-<div class="system-message" id="id77">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 1230); <em><a href="#id78">backlink</a></em></p>
-Unknown target name: "true".</div>
-<div class="system-message" id="id79">
-<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">/root/project/libs/parameter/doc/index.rst</tt>, line 2774); <em><a href="#id80">backlink</a></em></p>
-Unknown target name: "boost_parameter_match".</div>
</div>
</div>
<div class="footer">
<hr class="footer" />
-Generated on: 2019-08-14 12:05 UTC.
+Generated on: 2019-12-10 00:22 UTC.
Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
</div>
projects / platform / upstream / boost.git / blobdiff