fix broken link to logo

[SVN r21122]
This commit is contained in:
Beman Dawes 2003-12-03 14:36:38 +00:00
parent 8024c3e9c7
commit 61fb5a0b8f

View File

@ -4,7 +4,7 @@
<HEAD><TITLE>enable_if</TITLE> <HEAD><TITLE>enable_if</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.06"> <META name="GENERATOR" content="Microsoft FrontPage 5.0">
</HEAD> </HEAD>
<BODY > <BODY >
<!--HEVEA command line is: hevea -nosymb -noiso -pedantic -v enable_if_docs_for_boost.tex --> <!--HEVEA command line is: hevea -nosymb -noiso -pedantic -v enable_if_docs_for_boost.tex -->
@ -17,7 +17,7 @@
<h1> <h1>
<img border="0" src="c++boost.gif" align="center" width="277" height="86">enable_if</h1> <img border="0" src="../../c++boost.gif" align="center" width="277" height="86">enable_if</h1>
<BR> <BR>
<BR> <BR>
Copyright 2003 Jaakko J&auml;rvi, Jeremiah Willcock, Andrew Lumsdaine.<BR> Copyright 2003 Jaakko J&auml;rvi, Jeremiah Willcock, Andrew Lumsdaine.<BR>
@ -42,8 +42,7 @@ in&nbsp;[<A HREF="#jarvi:03:cuj_arbitrary_overloading"><CITE>1</CITE></A>] and&n
<H3><A NAME="htoc2">1.1</A>&nbsp;&nbsp;Synopsis</H3><!--SEC END --> <H3><A NAME="htoc2">1.1</A>&nbsp;&nbsp;Synopsis</H3><!--SEC END -->
<A NAME="sec:synopsis"></A> <A NAME="sec:synopsis"></A>
<PRE> <PRE>namespace boost {
namespace boost {
template &lt;class Cond, class T = void&gt; struct enable_if; template &lt;class Cond, class T = void&gt; struct enable_if;
template &lt;class Cond, class T = void&gt; struct disable_if; template &lt;class Cond, class T = void&gt; struct disable_if;
template &lt;class Cond, class T&gt; struct lazy_enable_if; template &lt;class Cond, class T&gt; struct lazy_enable_if;
@ -68,9 +67,7 @@ template, the instantiation is removed from the overload resolution
set instead of causing a compilation error. The following example, set instead of causing a compilation error. The following example,
taken from&nbsp;[<A HREF="#jarvi:03:cuj_arbitrary_overloading"><CITE>1</CITE></A>], taken from&nbsp;[<A HREF="#jarvi:03:cuj_arbitrary_overloading"><CITE>1</CITE></A>],
demonstrates why this is important: demonstrates why this is important:
<PRE> <PRE>int negate(int i) { return -i; }
int negate(int i) { return -i; }
template &lt;class F&gt; template &lt;class F&gt;
typename F::result_type negate(const F&amp; f) { return -f(); } typename F::result_type negate(const F&amp; f) { return -f(); }
@ -81,9 +78,7 @@ definition is obviously a better match, but the compiler must
nevertheless consider (and instantiate the prototypes) of both nevertheless consider (and instantiate the prototypes) of both
definitions to find this out. Instantiating the latter definition with definitions to find this out. Instantiating the latter definition with
<TT>F</TT> as <TT>int</TT> would result in: <TT>F</TT> as <TT>int</TT> would result in:
<PRE> <PRE>int::result_type negate(const int&amp;);
int::result_type negate(const int&amp;);
</PRE> </PRE>
where the return type is invalid. If this was an error, adding an unrelated function template where the return type is invalid. If this was an error, adding an unrelated function template
@ -111,9 +106,7 @@ The latter version interoperates with Boost.MPL. <BR>
<BR> <BR>
The definitions of <TT>enable_if_c</TT> and <TT>enable_if</TT> are as follows (we use <TT>enable_if</TT> templates The definitions of <TT>enable_if_c</TT> and <TT>enable_if</TT> are as follows (we use <TT>enable_if</TT> templates
unqualified but they are in the <TT>boost</TT> namespace). unqualified but they are in the <TT>boost</TT> namespace).
<PRE> <PRE>template &lt;bool B, class T = void&gt;
template &lt;bool B, class T = void&gt;
struct enable_if_c { struct enable_if_c {
typedef T type; typedef T type;
}; };
@ -136,9 +129,7 @@ The <TT>enable_if_c</TT> template can thus be used for controlling when function
overload resolution and when they are not. overload resolution and when they are not.
For example, the following function is defined for all arithmetic types (according to the For example, the following function is defined for all arithmetic types (according to the
classification of the <A HREF="http://www.boost.org/libs/type_traits">Boost type_traits library</A>): classification of the <A HREF="http://www.boost.org/libs/type_traits">Boost type_traits library</A>):
<PRE> <PRE>template &lt;class T&gt;
template &lt;class T&gt;
typename enable_if_c&lt;boost::is_arithmetic&lt;T&gt;::value, T&gt;::type typename enable_if_c&lt;boost::is_arithmetic&lt;T&gt;::value, T&gt;::type
foo(T t) { return t; } foo(T t) { return t; }
@ -146,9 +137,7 @@ foo(T t) { return t; }
The <TT>disable_if_c</TT> template is provided as well, and has the The <TT>disable_if_c</TT> template is provided as well, and has the
same functionality as <TT>enable_if_c</TT> except for the negated condition. The following same functionality as <TT>enable_if_c</TT> except for the negated condition. The following
function is enabled for all non-arithmetic types. function is enabled for all non-arithmetic types.
<PRE> <PRE>template &lt;class T&gt;
template &lt;class T&gt;
typename disable_if_c&lt;boost::is_arithmetic&lt;T&gt;::value, T&gt;::type typename disable_if_c&lt;boost::is_arithmetic&lt;T&gt;::value, T&gt;::type
bar(T t) { return t; } bar(T t) { return t; }
@ -160,9 +149,7 @@ The MPL <TT>bool_</TT>, <TT>and_</TT>, <TT>or_</TT>, and <TT>not_</TT> templates
useful for creating such types. Also, the traits classes in the Boost.Type_traits library useful for creating such types. Also, the traits classes in the Boost.Type_traits library
follow this convention. follow this convention.
For example, the above example function <TT>foo</TT> can be alternatively written as: For example, the above example function <TT>foo</TT> can be alternatively written as:
<PRE> <PRE>template &lt;class T&gt;
template &lt;class T&gt;
typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type
foo(T t) { return t; } foo(T t) { return t; }
@ -178,9 +165,7 @@ The <TT>enable_if</TT> templates are defined in
The <TT>enable_if</TT> template can be used either as the return type, or as an The <TT>enable_if</TT> template can be used either as the return type, or as an
extra argument. For example, the <TT>foo</TT> function in the previous section could also be written extra argument. For example, the <TT>foo</TT> function in the previous section could also be written
as: as:
<PRE> <PRE>template &lt;class T&gt;
template &lt;class T&gt;
T foo(T t, typename enable_if&lt;boost::is_arithmetic&lt;T&gt; &gt;::type* dummy = 0); T foo(T t, typename enable_if&lt;boost::is_arithmetic&lt;T&gt; &gt;::type* dummy = 0);
</PRE>Hence, an extra parameter of type <TT>void*</TT> is added, but it is given </PRE>Hence, an extra parameter of type <TT>void*</TT> is added, but it is given
@ -206,9 +191,7 @@ Class template specializations can be enabled or disabled with <TT>enable_if</TT
One extra template parameter needs to be added for the enabler expressions. One extra template parameter needs to be added for the enabler expressions.
This parameter has the default value <TT>void</TT>. This parameter has the default value <TT>void</TT>.
For example: For example:
<PRE> <PRE>template &lt;class T, class Enable = void&gt;
template &lt;class T, class Enable = void&gt;
class A { ... }; class A { ... };
template &lt;class T&gt; template &lt;class T&gt;
@ -236,9 +219,7 @@ rules are used to select the best matching function.
In particular, there is no ordering between enabling conditions. In particular, there is no ordering between enabling conditions.
Function templates with enabling conditions that are not mutually exclusive can Function templates with enabling conditions that are not mutually exclusive can
lead to ambiguities. For example: lead to ambiguities. For example:
<PRE> <PRE>template &lt;class T&gt;
template &lt;class T&gt;
typename enable_if&lt;boost::is_integral&lt;T&gt;, void&gt;::type typename enable_if&lt;boost::is_integral&lt;T&gt;, void&gt;::type
foo(T t) {} foo(T t) {}
@ -263,9 +244,7 @@ partial specializations as well.<BR>
<A NAME="sec:enable_if_lazy"></A> <A NAME="sec:enable_if_lazy"></A>
In some cases it is necessary to avoid instantiating part of a In some cases it is necessary to avoid instantiating part of a
function signature unless an enabling condition is true. For example: function signature unless an enabling condition is true. For example:
<PRE> <PRE>template &lt;class T, class U&gt; class mult_traits;
template &lt;class T, class U&gt; class mult_traits;
template &lt;class T, class U&gt; template &lt;class T, class U&gt;
typename enable_if&lt;is_multipliable&lt;T, U&gt;, typename mult_traits&lt;T, U&gt;::type&gt;::type typename enable_if&lt;is_multipliable&lt;T, U&gt;, typename mult_traits&lt;T, U&gt;::type&gt;::type
@ -284,9 +263,7 @@ The SFINAE principle is not applied because
the invalid type occurs as an argument to another template. The <TT>lazy_enable_if</TT> the invalid type occurs as an argument to another template. The <TT>lazy_enable_if</TT>
and <TT>lazy_disable_if</TT> templates (and their <TT>_c</TT> versions) can be used in such and <TT>lazy_disable_if</TT> templates (and their <TT>_c</TT> versions) can be used in such
situations: situations:
<PRE> <PRE>template&lt;class T, class U&gt;
template&lt;class T, class U&gt;
typename lazy_enable_if&lt;is_multipliable&lt;T, U&gt;, mult_traits&lt;T, U&gt; &gt;::type typename lazy_enable_if&lt;is_multipliable&lt;T, U&gt;, mult_traits&lt;T, U&gt; &gt;::type
operator*(const T&amp; t, const U&amp; u) { ... } operator*(const T&amp; t, const U&amp; u) { ... }
@ -314,9 +291,7 @@ above example, <TT>is_multipliable&lt;T, U&gt;::value</TT> defines when
Some compilers flag functions as ambiguous if the only distinguishing factor is a different Some compilers flag functions as ambiguous if the only distinguishing factor is a different
condition in an enabler (even though the functions could never be ambiguous). For example, condition in an enabler (even though the functions could never be ambiguous). For example,
some compilers (e.g. GCC 3.2) diagnose the following two functions as ambiguous: some compilers (e.g. GCC 3.2) diagnose the following two functions as ambiguous:
<PRE> <PRE>template &lt;class T&gt;
template &lt;class T&gt;
typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type
foo(T t); foo(T t);
@ -328,9 +303,7 @@ foo(T t);
<UL><LI> <UL><LI>
Use an extra dummy parameter which disambiguates the functions. Use a default value for Use an extra dummy parameter which disambiguates the functions. Use a default value for
it to hide the parameter from the caller. For example: it to hide the parameter from the caller. For example:
<PRE> <PRE>template &lt;class T&gt; struct dummy { dummy(int) {} };
template &lt;class T&gt; struct dummy { dummy(int) {} };
template &lt;class T&gt; template &lt;class T&gt;
typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type
@ -343,9 +316,7 @@ foo(T t, dummy&lt;1&gt; = 0);
<BR> <BR>
<LI>Define the functions in different namespaces and bring them into a common <LI>Define the functions in different namespaces and bring them into a common
namespace with <TT>using</TT> declarations: namespace with <TT>using</TT> declarations:
<PRE> <PRE>namespace A {
namespace A {
template &lt;class T&gt; template &lt;class T&gt;
typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type typename enable_if&lt;boost::is_arithmetic&lt;T&gt;, T&gt;::type
foo(T t); foo(T t);
@ -414,4 +385,4 @@ Open Systems Lab
</EM><A HREF="http://pauillac.inria.fr/~maranget/hevea/index.html"><EM>H<FONT SIZE=2><sup>E</sup></FONT>V<FONT SIZE=2><sup>E</sup></FONT>A</EM></A><EM>. </EM><A HREF="http://pauillac.inria.fr/~maranget/hevea/index.html"><EM>H<FONT SIZE=2><sup>E</sup></FONT>V<FONT SIZE=2><sup>E</sup></FONT>A</EM></A><EM>.
</EM></BLOCKQUOTE> </EM></BLOCKQUOTE>
</BODY> </BODY>
</HTML> </HTML>