diff --git a/call_traits.htm b/call_traits.htm index 78cb60f..c801243 100644 --- a/call_traits.htm +++ b/call_traits.htm @@ -34,9 +34,9 @@ specialization or member templates, no benefit will occur from using call_traits: the call_traits defined types will always be the same as the existing practice in this case. In addition if only member templates and not partial template specialisation is -support by the compiler (for example Visual C++ 6) then call_traits -can not be used with array types (although it can be used to -solve the reference to reference problem).

+support by the compiler (for example Visual C++ 6) then +call_traits can not be used with array types (although it can be +used to solve the reference to reference problem).

@@ -79,7 +79,8 @@ solve the reference to reference problem).

- -

const T&
+

const + T&
(return value)

call_traits<T>::const_reference

@@ -91,7 +92,8 @@ solve the reference to reference problem).

const T&
+

const + T&
(function parameter)

call_traits<T>::param_type

@@ -332,8 +334,8 @@ possible:

The following table shows the effect that call_traits has on various types, the table assumes that the compiler supports partial specialization: if it doesn't then all types behave in -the same way as the entry for "myclass", and call_traits -can not be used with reference or array types.

+the same way as the entry for "myclass", and +call_traits can not be used with reference or array types.

@@ -388,7 +390,8 @@ can not be used with reference or array types.

- @@ -420,7 +423,8 @@ can not be used with reference or array types.

- @@ -432,13 +436,17 @@ can not be used with reference or array types.

- - - -

int&

const int&

+

const + int&

int const

int&

const int&

+

const + int&

int&

const int&

const int&

+

const + int&

const int&

+

const + int&

const int&

+

const + int&

const int&

+

const + int&

All constant-references.

@@ -486,8 +494,8 @@ can not be used with reference or array types.

The following class is a trivial class that stores some type T by value (see the call_traits_test.cpp -file), the aim is to illustrate how each of the available call_traits -typedefs may be used:

+file), the aim is to illustrate how each of the available +call_traits typedefs may be used:

template <class T>
 struct contained
@@ -523,14 +531,14 @@ problem):
 
 
template <class Operation> 
 class binder1st : 
-   public unary_function<Operation::second_argument_type, Operation::result_type> 
+   public unary_function<typename Operation::second_argument_type, typename Operation::result_type> 
 { 
 protected: 
    Operation op; 
-   Operation::first_argument_type value; 
+   typename Operation::first_argument_type value; 
 public: 
-   binder1st(const Operation& x, const Operation::first_argument_type& y); 
-   Operation::result_type operator()(const Operation::second_argument_type& x) const; 
+   binder1st(const Operation& x, const typename Operation::first_argument_type& y); 
+   typename Operation::result_type operator()(const typename Operation::second_argument_type& x) const; 
 }; 

 
 
Now consider what happens in the relatively common case that
@@ -541,7 +549,7 @@ reference to a reference as an argument, and that is not
 currently legal. The solution here is to modify operator()
 to use call_traits:

 
-
Operation::result_type operator()(call_traits<Operation::second_argument_type>::param_type x) const;

+
typename Operation::result_type operator()(typename call_traits<typename Operation::second_argument_type>::param_type x) const;

 
 
Now in the case that Operation::second_argument_type
 is a reference type, the argument is passed as a reference, and
@@ -575,9 +583,9 @@ std::pair<
 degraded to pointers if the deduced types are arrays, similar
 situations occur in the standard binders and adapters: in
 principle in any function that "wraps" a temporary
-whose type is deduced. Note that the function arguments to make_pair
-are not expressed in terms of call_traits: doing so would prevent
-template argument deduction from functioning.

+whose type is deduced. Note that the function arguments to
+make_pair are not expressed in terms of call_traits: doing so
+would prevent template argument deduction from functioning.

 
 
Example 4 (optimising fill):

 
@@ -666,10 +674,10 @@ be any worse than existing practice.

 
Pointers follow the same rational as small built-in types.

 
 
For reference types the rational follows Example
-2 - references to references are not allowed, so the call_traits
-members must be defined such that these problems do not occur.
-There is a proposal to modify the language such that "a
-reference to a reference is a reference" (issue #106,
+2 - references to references are not allowed, so the
+call_traits members must be defined such that these problems do
+not occur. There is a proposal to modify the language such that
+"a reference to a reference is a reference" (issue #106,
 submitted by Bjarne Stroustrup), call_traits<T>::value_type
 and call_traits<T>::param_type both provide the same effect
 as that proposal, without the need for a language change (in
@@ -687,11 +695,11 @@ struct A
    void foo(T t);
 };
-

In this case if we instantiate A<int[2]> -then the declared type of the parameter passed to member function -foo is int[2], but it's actual type is const int*, if we try to -use the type T within the function body, then there is a strong -likelyhood that our code will not compile:

+

In this case if we instantiate +A<int[2]> then the declared type of the parameter passed to +member function foo is int[2], but it's actual type is const int*, +if we try to use the type T within the function body, then there +is a strong likelyhood that our code will not compile:

template <class T>
 void A<T>::foo(T t)
@@ -706,13 +714,13 @@ declared type:

 
template <class T>
 struct A
 {
-   void foo(call_traits<T>::value_type t);
+   void foo(typename call_traits<T>::value_type t);
 };
 
 template <class T>
-void A<T>::foo(call_traits<T>::value_type t)
+void A<T>::foo(typename call_traits<T>::value_type t)
 {
-   call_traits<T>::value_type dup(t); // OK even if T is an array type.
+   typename call_traits<T>::value_type dup(t); // OK even if T is an array type.
 }

 
 
For value_type (return by value), again only a pointer may be