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
diff --git a/include/boost/operators.hpp b/include/boost/operators.hpp
index 482a25a..e6a2cb0 100644
--- a/include/boost/operators.hpp
+++ b/include/boost/operators.hpp
@@ -15,6 +15,8 @@
 //  See http://www.boost.org for most recent version including documentation.
 
 //  Revision History
+//  11 Feb 01 Fixed bugs in the iterator helpers which prevented explicitly
+//            supplied arguments from actually being used (Dave Abrahams)
 //  04 Jul 00 Fixed NO_OPERATORS_IN_NAMESPACE bugs, major cleanup and
 //            refactoring of compiler workarounds, additional documentation
 //            (Alexy Gurtovoy and Mark Rodgers with some help and prompting from
@@ -514,7 +516,7 @@ struct forward_iterator_helper
   : equality_comparable > > > {};
 
 template  > > > > {};
 
 template  > > > > > > > >
 {
 #ifndef __BORLANDC__
diff --git a/utility.htm b/utility.htm
index e0f090f..fc0652a 100644
--- a/utility.htm
+++ b/utility.htm
@@ -81,7 +81,7 @@ CodeWarrior 5.0, and Microsoft Visual C++ 6.0 sp 3.

   
// inside one of your own headers ...
 #include <boost/utility.hpp>
 
-class ResourceLadenFileSystem : noncopyable {
+class ResourceLadenFileSystem : boost::noncopyable {
 ...

 
 
@@ -93,7 +93,7 @@ destructor declarations. He says "Probably this concern is misplaced, becau
 noncopyable will be used mostly for classes which own resources and thus have non-trivial destruction semantics."

 

 
Revised  28 September, 200016 February, 2001
 

 
© Copyright boost.org 1999. Permission to copy, use, modify, sell and