From 61fb5a0b8ff8e2ae6e3e090af9cab21a640e7603 Mon Sep 17 00:00:00 2001 From: Beman Dawes Date: Wed, 3 Dec 2003 14:36:38 +0000 Subject: [PATCH] fix broken link to logo [SVN r21122] --- enable_if.html | 65 ++++++++++++++------------------------------------ 1 file changed, 18 insertions(+), 47 deletions(-) diff --git a/enable_if.html b/enable_if.html index 349189e..eb485c5 100644 --- a/enable_if.html +++ b/enable_if.html @@ -4,7 +4,7 @@ enable_if - + @@ -17,7 +17,7 @@

-enable_if

+enable_if

Copyright 2003 Jaakko Järvi, Jeremiah Willcock, Andrew Lumsdaine.
@@ -42,8 +42,7 @@ in [1] and&n

1.1  Synopsis

-
-namespace boost {
+
namespace boost {
   template <class Cond, class T = void> struct enable_if;
   template <class Cond, class T = void> struct disable_if;
   template <class Cond, class T> 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, 
 taken from [1],
 demonstrates why this is important:
-
-
-int negate(int i) { return -i; }
+
int negate(int i) { return -i; }
 
 template <class F>
 typename F::result_type negate(const F& 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
 definitions to find this out. Instantiating the latter definition with
 F as int would result in:
-
-
-int::result_type negate(const int&);
+
int::result_type negate(const int&);
 
 

 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. 

 

 The definitions of enable_if_c and enable_if are as follows (we use enable_if templates 
 unqualified but they are in the boost namespace).
-
-
-template <bool B, class T = void>
+
template <bool B, class T = void>
 struct enable_if_c {
   typedef T type;
 };
@@ -136,9 +129,7 @@ The enable_if_c template can thus be used for controlling when function
 overload resolution and when they are not. 
 For example, the following function is defined for all arithmetic types (according to the
 classification of the Boost type_traits library):
-
-
-template <class T>
+
template <class T>
 typename enable_if_c<boost::is_arithmetic<T>::value, T>::type 
 foo(T t) { return t; }
 
@@ -146,9 +137,7 @@ foo(T t) { return t; }
 The disable_if_c template is provided as well, and has the
 same functionality as enable_if_c except for the negated condition. The following
 function is enabled for all non-arithmetic types.
-
-
-template <class T>
+
template <class T>
 typename disable_if_c<boost::is_arithmetic<T>::value, T>::type 
 bar(T t) { return t; }
 
@@ -160,9 +149,7 @@ The MPL bool_, and_, or_, and not_ templates
 useful for creating such types. Also, the traits classes in the Boost.Type_traits library 
 follow this convention. 
 For example, the above example function foo can be alternatively written as:
-
-
-template <class T>
+
template <class T>
 typename enable_if<boost::is_arithmetic<T>, T>::type 
 foo(T t) { return t; }
 
@@ -178,9 +165,7 @@ The enable_if templates are defined in
 The enable_if template can be used either as the return type, or as an 
 extra argument. For example, the foo function in the previous section could also be written
 as:
-
-
-template <class T>
+
template <class T>
 T foo(T t, typename enable_if<boost::is_arithmetic<T> >::type* dummy = 0); 
 
 
Hence, an extra parameter of type void* is added, but it is given 
@@ -206,9 +191,7 @@ Class template specializations can be enabled or disabled with enable_ifvoid.
 For example:
-
-
-template <class T, class Enable = void> 
+
template <class T, class Enable = void> 
 class A { ... };
 
 template <class T>
@@ -236,9 +219,7 @@ rules are used to select the best matching function.
 In particular, there is no ordering between enabling conditions.
 Function templates with enabling conditions that are not mutually exclusive can 
 lead to ambiguities. For example:
-
-
-template <class T>
+
template <class T>
 typename enable_if<boost::is_integral<T>, void>::type 
 foo(T t) {}
 
@@ -263,9 +244,7 @@ partial specializations as well.

 
 In some cases it is necessary to avoid instantiating part of a
 function signature unless an enabling condition is true. For example:
-
-
-template <class T, class U> class mult_traits;
+
template <class T, class U> class mult_traits;
 
 template <class T, class U>
 typename enable_if<is_multipliable<T, U>, typename mult_traits<T, U>::type>::type
@@ -284,9 +263,7 @@ The SFINAE principle is not applied because
 the invalid type occurs as an argument to another template. The lazy_enable_if 
 and lazy_disable_if templates (and their _c versions) can be used in such
 situations:
-
-
-template<class T, class U>
+
template<class T, class U>
 typename lazy_enable_if<is_multipliable<T, U>, mult_traits<T, U> >::type
 operator*(const T& t, const U& u) { ... }
 
@@ -314,9 +291,7 @@ above example, is_multipliable<T, U>::value defines when
 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,
 some compilers (e.g. GCC 3.2) diagnose the following two functions as ambiguous:
-
-
-template <class T>
+
template <class T>
 typename enable_if<boost::is_arithmetic<T>, T>::type 
 foo(T t);
 
@@ -328,9 +303,7 @@ foo(T t);
 
  • 
 Use an extra dummy parameter which disambiguates the functions. Use a default value for
 it to hide the parameter from the caller. For example:
-
    -
-template <class T> struct dummy { dummy(int) {} };
+
    template <class T> struct dummy { dummy(int) {} };
 
 template <class T>
 typename enable_if<boost::is_arithmetic<T>, T>::type 
@@ -343,9 +316,7 @@ foo(T t, dummy<1> = 0);
 
    
 
  • Define the functions in different namespaces and bring them into a common
 namespace with using declarations:
-
    -
-namespace A {
+
    namespace A {
   template <class T>
   typename enable_if<boost::is_arithmetic<T>, T>::type 
   foo(T t);
@@ -414,4 +385,4 @@ Open Systems Lab
 HEVEA.
 
 
-
+
\ No newline at end of file