Date: Thu, 7 Jun 2007 20:53:46 +0000
Subject: [PATCH] This commit was manufactured by cvs2svn to create tag
'merged_to_RC_1_34_0'.
[SVN r37938]
---
Assignable.html | 199 ++--
Collection.html | 1036 ++++++++---------
CopyConstructible.html | 303 +++--
LessThanComparable.html | 394 ++++---
MultiPassInputIterator.html | 157 +--
assert.html | 7 +-
call_traits.htm | 3 +-
checked_delete.html | 7 +-
current_function.html | 7 +-
generator_iterator.htm | 173 +--
in_place_factories.html | 9 +-
include/boost/current_function.hpp | 4 -
.../utility/detail/result_of_iterate.hpp | 14 +-
include/boost/utility/result_of.hpp | 7 +-
throw_exception.html | 7 +-
15 files changed, 1098 insertions(+), 1229 deletions(-)
diff --git a/Assignable.html b/Assignable.html
index 557f4e7..54934f1 100644
--- a/Assignable.html
+++ b/Assignable.html
@@ -1,116 +1,109 @@
-
-
-
-Assignable
-
-
-
-
-
-Assignable
+
-Description
-A type is Assignable if it is possible to assign one object of the type
-to another object of that type.
+
+
+
+
+ Assignable
+
-Notation
-
-
-
-T
- |
-
-is type that is a model of Assignable
- |
-
+
+ 
-
-
-t
- |
-
-is an object of type T
- |
-
+ Assignable
-
-
-u
- |
-
-is an object of type T or possibly const T
- |
-
+ Description
-
-Definitions
-Valid expressions
-
-
-
-Name
- |
-
-Expression
- |
-
-Return type
- |
-
-Semantics
- |
-
-
-
-Assignment
- |
-
-t = u
- |
-
-T&
- |
-
-t is equivalent to u
- |
-
+ A type is Assignable if it is possible to assign one object of the type
+ to another object of that type.
-
+ Notation
+
-Models
+ is type that is a model of Assignable |
+
-
+
+ t |
-See also
-DefaultConstructible
-and
-CopyConstructible
+ is an object of type T |
+
-
-
-
+
+ u |
-
-
+ is an object of type T or possibly const
+ T |
+
+
+
+ Definitions
+
+ Valid expressions
+
+
+
+ Name |
+
+ Expression |
+
+ Return type |
+
+ Semantics |
+
+
+
+ Assignment |
+
+ t = u |
+
+ T& |
+
+ t is equivalent to u |
+
+
+
+ Models
+
+
+
+ See also
+
+ DefaultConstructible
+ and CopyConstructible
+
+
+ 
+
+ Revised
+ 05 December, 2006
+
+
+
+ Distributed under the Boost Software License, Version 1.0. (See
+ accompanying file LICENSE_1_0.txt or
+ copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
diff --git a/Collection.html b/Collection.html
index 9069e28..c811e7e 100644
--- a/Collection.html
+++ b/Collection.html
@@ -1,244 +1,190 @@
-
-
-
-Collection
-
+
-
-
-
-
Collection
-
+
+
+
+
-Description
+ Collection
+
-A Collection is a concept similar to the STL Container
-concept. A Collection provides iterators for accessing a range of
-elements and provides information about the number of elements in the
-Collection. However, a Collection has fewer requirements than a
-Container. The motivation for the Collection concept is that there are
-many useful Container-like types that do not meet the full
-requirements of Container, and many algorithms that can be written
-with this reduced set of requirements. To summarize the reduction
-in requirements:
+
+ 
+ Collection
-
-- It is not required to "own" its elements: the lifetime
-of an element in a Collection does not have to match the lifetime of
-the Collection object, though the lifetime of the element should cover
-the lifetime of the Collection object.
-
- The semantics of copying a Collection object is not defined (it
-could be a deep or shallow copy or not even support copying).
-
- The associated reference type of a Collection does
-not have to be a real C++ reference.
-
+ Description
+ A Collection is a concept similar to the STL Container concept. A
+ Collection provides iterators for accessing a range of elements and
+ provides information about the number of elements in the Collection.
+ However, a Collection has fewer requirements than a Container. The
+ motivation for the Collection concept is that there are many useful
+ Container-like types that do not meet the full requirements of Container,
+ and many algorithms that can be written with this reduced set of
+ requirements. To summarize the reduction in requirements:
-Because of the reduced requirements, some care must be taken when
-writing code that is meant to be generic for all Collection types.
-In particular, a Collection object should be passed by-reference
-since assumptions can not be made about the behaviour of the
-copy constructor.
+
+ - It is not required to "own" its elements: the lifetime of an element
+ in a Collection does not have to match the lifetime of the Collection
+ object, though the lifetime of the element should cover the lifetime of
+ the Collection object.
-
+
- The semantics of copying a Collection object is not defined (it could
+ be a deep or shallow copy or not even support copying).
-Associated types
+ - The associated reference type of a Collection does not have to be a
+ real C++ reference.
+
Because of the reduced requirements, some care must be taken when
+ writing code that is meant to be generic for all Collection types. In
+ particular, a Collection object should be passed by-reference since
+ assumptions can not be made about the behaviour of the copy constructor.
-
-
-
-Value type
- |
-
-X::value_type
- |
-
-The type of the object stored in a Collection.
-If the Collection is mutable then
-the value type must be Assignable.
-Otherwise the value type must be CopyConstructible.
- |
-
-
-
-Iterator type
- |
-
-X::iterator
- |
-
-The type of iterator used to iterate through a Collection's
- elements. The iterator's value type is expected to be the
- Collection's value type. A conversion
- from the iterator type to the const iterator type must exist.
- The iterator type must be an InputIterator.
- |
-
-
-
-Const iterator type
- |
-
-X::const_iterator
- |
-
-A type of iterator that may be used to examine, but not to modify,
- a Collection's elements.
- |
-
-
-
-Reference type
- |
-
-X::reference
- |
-
-A type that behaves like a reference to the Collection's value type.
-[1]
- |
-
-
-
-Const reference type
- |
-
-X::const_reference
- |
-
-A type that behaves like a const reference to the Collection's value type.
- |
-
-
-
-Pointer type
- |
-
-X::pointer
- |
-
-A type that behaves as a pointer to the Collection's value type.
- |
-
-
-
-Distance type
- |
-
-X::difference_type
- |
-
-A signed integral type used to represent the distance between two
- of the Collection's iterators. This type must be the same as
- the iterator's distance type.
- |
-
-
-
-Size type
- |
-
-X::size_type
- |
-
-An unsigned integral type that can represent any nonnegative value
- of the Collection's distance type.
- |
-
-
-Notation
-
-
-
-X
- |
-
-A type that is a model of Collection.
- |
-
-
-
-a, b
- |
-
-Object of type X.
- |
-
-
-
-T
- |
-
-The value type of X.
- |
-
-
+ Associated types
-Valid expressions
+
+
+ Value type |
-The following expressions must be valid.
-
+
X::value_type |
-
-
-
-Name
- |
-
-Expression
- |
-
-Return type
- |
-
-
-
-Beginning of range
- |
-
-a.begin()
- |
-
-iterator if a is mutable, const_iterator otherwise
- |
-
-
-
-End of range
- |
-
-a.end()
- |
-
-iterator if a is mutable, const_iterator otherwise
- |
-
-
-
-Size
- |
-
-a.size()
- |
-
-size_type
- |
-
-
-
-Empty Collection
- |
-
-a.empty()
- |
-
-Convertible to bool
- |
-
-
-
-Swap
- |
-
-a.swap(b)
- |
-
-void
- |
-
-
-Expression semantics
-
-
-
-Name
- |
-
-Expression
- |
-
-Semantics
- |
-
-Postcondition
- |
-
-
- |
-
-Beginning of range
- |
-
-a.begin()
- |
-
-Returns an iterator pointing to the first element in the Collection.
- |
-
-a.begin() is either dereferenceable or past-the-end. It is
- past-the-end if and only if a.size() == 0.
- |
-
-
-
-End of range
- |
-
-a.end()
- |
-
-Returns an iterator pointing one past the last element in the
- Collection.
- |
-
-a.end() is past-the-end.
- |
-
-
-
-Size
- |
-
-a.size()
- |
-
-Returns the size of the Collection, that is, its number of elements.
- |
-
-a.size() >= 0
- |
-
-
-
-
-Empty Collection
- |
-
-a.empty()
- |
-
-Equivalent to a.size() == 0. (But possibly faster.)
- |
-
-
- |
-
-
-
-Swap
- |
-
-a.swap(b)
- |
-
-Equivalent to swap(a,b)
- |
-
-
- |
-
-
-Complexity guarantees
-begin() and end() are amortized constant time.
-
-size() is at most linear in the Collection's
-size. empty() is amortized constant time.
-
-swap() is at most linear in the size of the two collections.
-
Invariants
-
-
-
-Valid range
- |
-
-For any Collection a, [a.begin(), a.end()) is a valid
- range.
- |
-
-
-
-Range size
- |
-
-a.size() is equal to the distance from a.begin() to a.end().
- |
-
-
-
-Completeness
- |
-
-An algorithm that iterates through the range [a.begin(), a.end())
- will pass through every element of a.
- |
-
-
+
+ Empty Collection |
+ a.empty() |
-Models
-
-- array
-
- array_ptr
-
- vector<bool>
-
+ Equivalent to a.size() == 0. (But possibly
+ faster.) |
+ |
+
-Collection Refinements
+
+ Swap |
-There are quite a few concepts that refine the Collection concept,
-similar to the concepts that refine the Container concept. Here
-is a brief overview of the refining concepts.
+ a.swap(b) |
-ForwardCollection
-The elements are arranged in some order that
-does not change spontaneously from one iteration to the next. As
-a result, a ForwardCollection is
-EqualityComparable
-and
-LessThanComparable.
-In addition, the iterator type of a ForwardCollection is a
-MultiPassInputIterator which is just an InputIterator with the added
-requirements that the iterator can be used to make multiple passes
-through a range, and that if it1 == it2 and it1 is
-dereferenceable then ++it1 == ++it2. The ForwardCollection
-also has a front() method.
+ Equivalent to swap(a,b) |
-
-
-
-
-Name
- |
-
-Expression
- |
-
-Return type
- |
-
-Semantics
- |
-
+ |
+
+
-
-
-Front
- |
-
-a.front()
- |
-
-reference if a is mutable, const_reference
-otherwise.
- |
-
-Equivalent to *(a.begin()).
- |
-
+ Complexity guarantees
-
+ begin() and end() are amortized constant time.
+ size() is at most linear in the Collection's size.
+ empty() is amortized constant time.
-ReversibleCollection
+ swap() is at most linear in the size of the two
+ collections.
-The container provides access to iterators that traverse in both
-directions (forward and reverse). The iterator type must meet all of
-the requirements of
-BidirectionalIterator
-except that the reference type does not have to be a real C++
-reference. The ReversibleCollection adds the following requirements
-to those of ForwardCollection.
-
+
Invariants
-
-
-
-Name
- |
-
-Expression
- |
-
-Return type
- |
-
-Semantics
- |
-
-
-
-Beginning of range
- |
-
-a.rbegin()
- |
-
-reverse_iterator if a is mutable,
-const_reverse_iterator otherwise.
- |
-
-Equivalent to X::reverse_iterator(a.end()).
- |
-
-
-
-End of range
- |
-
-a.rend()
- |
-
-reverse_iterator if a is mutable,
-const_reverse_iterator otherwise.
- |
-
-Equivalent to X::reverse_iterator(a.begin()).
- |
-
+
+
+ Valid range |
-
-
-Back
- |
-
-a.back()
- |
-
-reference if a is mutable, const_reference
-otherwise.
- |
-
-Equivalent to *(--a.end()).
- |
-
+ For any Collection a, [a.begin(),
+ a.end()) is a valid range. |
+
-
+
+ Range size |
-SequentialCollection
+ a.size() is equal to the distance from
+ a.begin() to a.end(). |
+
-The elements are arranged in a strict linear order. No extra methods
-are required.
+
+ Completeness |
-RandomAccessCollection
+ An algorithm that iterates through the range
+ [a.begin(), a.end()) will pass through every element of
+ a. |
+
+
-The iterators of a RandomAccessCollection satisfy all of the
-requirements of RandomAccessIterator
-except that the reference type does not have to be a real C++
-reference. In addition, a RandomAccessCollection provides
-an element access operator.
+ Models
-
+
+ - array
-
-
-
-Name
- |
-
-Expression
- |
-
-Return type
- |
-
-Semantics
- |
-
-
-
-Element Access
- |
-
-a[n]
- |
-
-reference if a is mutable,
-const_reference otherwise.
- |
-
-Returns the nth element of the Collection.
-n must be convertible to size_type.
-Precondition: 0 <= n < a.size().
- |
-
+ - array_ptr
-
+ - vector<bool>
+
-Notes
+ Collection Refinements
-[1]
+
There are quite a few concepts that refine the Collection concept,
+ similar to the concepts that refine the Container concept. Here is a brief
+ overview of the refining concepts.
-The reference type does not have to be a real C++ reference. The
-requirements of the reference type depend on the context within which
-the Collection is being used. Specifically it depends on the
-requirements the context places on the value type of the Collection.
-The reference type of the Collection must meet the same requirements
-as the value type. In addition, the reference objects must be
-equivalent to the value type objects in the collection (which is
-trivially true if they are the same object). Also, in a mutable
-Collection, an assignment to the reference object must result in an
-assignment to the object in the Collection (again, which is trivially
-true if they are the same object, but non-trivial if the reference
-type is a proxy class).
+ ForwardCollection
-See also
-Container
+ The elements are arranged in some order that does not change
+ spontaneously from one iteration to the next. As a result, a
+ ForwardCollection is EqualityComparable
+ and LessThanComparable.
+ In addition, the iterator type of a ForwardCollection is a
+ MultiPassInputIterator which is just an InputIterator with the added
+ requirements that the iterator can be used to make multiple passes through
+ a range, and that if it1 == it2 and it1 is
+ dereferenceable then ++it1 == ++it2. The ForwardCollection also
+ has a front() method.
+
+
+ Name |
-
-
-
+ Expression |
-
-
+ Return type |
+
+ Semantics |
+
+
+
+ Front |
+
+ a.front() |
+
+ reference if a is mutable,
+ const_reference otherwise. |
+
+ Equivalent to *(a.begin()). |
+
+
+
+ ReversibleCollection
+
+ The container provides access to iterators that traverse in both
+ directions (forward and reverse). The iterator type must meet all of the
+ requirements of BidirectionalIterator
+ except that the reference type does not have to be a real C++ reference.
+ The ReversibleCollection adds the following requirements to those of
+ ForwardCollection.
+
+
+
+ Name |
+
+ Expression |
+
+ Return type |
+
+ Semantics |
+
+
+
+ Beginning of range |
+
+ a.rbegin() |
+
+ reverse_iterator if a is mutable,
+ const_reverse_iterator otherwise. |
+
+ Equivalent to
+ X::reverse_iterator(a.end()). |
+
+
+
+ End of range |
+
+ a.rend() |
+
+ reverse_iterator if a is mutable,
+ const_reverse_iterator otherwise. |
+
+ Equivalent to
+ X::reverse_iterator(a.begin()). |
+
+
+
+ Back |
+
+ a.back() |
+
+ reference if a is mutable,
+ const_reference otherwise. |
+
+ Equivalent to *(--a.end()). |
+
+
+
+ SequentialCollection
+
+ The elements are arranged in a strict linear order. No extra methods are
+ required.
+
+ RandomAccessCollection
+
+ The iterators of a RandomAccessCollection satisfy all of the
+ requirements of RandomAccessIterator
+ except that the reference type does not have to be a real C++ reference. In
+ addition, a RandomAccessCollection provides an element access operator.
+
+
+
+ Name |
+
+ Expression |
+
+ Return type |
+
+ Semantics |
+
+
+
+ Element Access |
+
+ a[n] |
+
+ reference if a is mutable,
+ const_reference otherwise. |
+
+ Returns the nth element of the Collection. n
+ must be convertible to size_type. Precondition: 0 <= n
+ < a.size(). |
+
+
+
+ Notes
+
+ [1] The reference type does not have to be a
+ real C++ reference. The requirements of the reference type depend on the
+ context within which the Collection is being used. Specifically it depends
+ on the requirements the context places on the value type of the Collection.
+ The reference type of the Collection must meet the same requirements as the
+ value type. In addition, the reference objects must be equivalent to the
+ value type objects in the collection (which is trivially true if they are
+ the same object). Also, in a mutable Collection, an assignment to the
+ reference object must result in an assignment to the object in the
+ Collection (again, which is trivially true if they are the same object, but
+ non-trivial if the reference type is a proxy class).
+
+ See also
+
+ Container
+
+
+ 
+
+ Revised
+ 05
+ December, 2006
+
+
+
+ Distributed under the Boost Software License, Version 1.0. (See
+ accompanying file LICENSE_1_0.txt or
+ copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
diff --git a/CopyConstructible.html b/CopyConstructible.html
index f2d6308..40ff7a7 100644
--- a/CopyConstructible.html
+++ b/CopyConstructible.html
@@ -1,178 +1,139 @@
-
-
-
-Copy Constructible
-
-
-
-
-
-Copy Constructible
+
-Description
-A type is Copy Constructible if it is possible to copy objects of that
-type.
+
+
+
+
-Notation
-
-
-
-T
- |
-
-is type that is a model of Copy Constructible
- |
-
+ Copy Constructible
+
-
-
-t
- |
-
-is an object of type T
- |
-
+
+ 
-
-
-u
- |
-
-is an object of type const T
- |
-
+ Copy Constructible
-
-Definitions
-Valid expressions
-
-
-
-Name
- |
-
-Expression
- |
-
-Return type
- |
-
-Semantics
- |
-
-
-
-Copy constructor
- |
-
-T(t)
- |
-
-T
- |
-
-t is equivalent to T(t)
- |
-
+ Description
+ A type is Copy Constructible if it is possible to copy objects of that
+ type.
-
-
-Copy constructor
- |
-
-
+ Notation
+
+
+
+ T |
+
+ is type that is a model of Copy Constructible |
+
+
+
+ t |
+
+ is an object of type T |
+
+
+
+ u |
+
+ is an object of type const T |
+
+
+
+ Definitions
+
+ Valid expressions
+
+
+
+ Name |
+
+ Expression |
+
+ Return type |
+
+ Semantics |
+
+
+
+ Copy constructor |
+
+ T(t) |
+
+ T |
+
+ t is equivalent to T(t) |
+
+
+
+ Copy constructor |
+
+
+
T(u)
- |
-
-T
- |
-
-u is equivalent to T(u)
- |
-
+
+ T |
-
-
-Destructor
- |
-
-
+ u is equivalent to T(u) |
+ |
+
+
+ Destructor |
+
+
+
t.~T()
- |
-
-T
- |
-
-
- |
-
+
-
-
-Address Operator
- |
-
-
+ T |
+
+ |
+ |
+
+
+ Address Operator |
+
+
+
&t
- |
-
-T*
- |
-
-denotes the address of t
- |
-
+
-
-
-Address Operator
- |
-
-
+ T* |
+
+ denotes the address of t |
+ |
+
+
+ Address Operator |
+
+
+
&u
- |
-
-T*
- |
-
-denotes the address of u
- |
-
+
+ T* |
+ denotes the address of u |
+
+
- |
+ Models
+
+ - int
-
-Models
+ - std::pair
+
-
-
-Concept Checking Class
-
-
+ Concept Checking Class
+
template <class T>
struct CopyConstructibleConcept
{
@@ -192,19 +153,33 @@ denotes the address of u
};
-See also
-Default Constructible
-and
-Assignable
+ See also
-
-
-
+ Default
+ Constructible and Assignable
+
-
-
+ 
+
+ Revised
+ 05
+ December, 2006
+
+
+
+ Distributed under the Boost Software License, Version 1.0. (See
+ accompanying file LICENSE_1_0.txt or
+ copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
diff --git a/LessThanComparable.html b/LessThanComparable.html
index 8913b38..a723377 100644
--- a/LessThanComparable.html
+++ b/LessThanComparable.html
@@ -1,212 +1,210 @@
-
+
+
+
-
-
-LessThanComparable
-
-
-
-
-
-LessThanComparable
-Description
-A type is LessThanComparable if it is ordered: it must
-be possible to compare two objects of that type using operator<, and
-operator< must be a strict weak ordering relation.
+
+
+
+ LessThanComparable
+
-Refinement of
-Associated types
-Notation
-
-
-
-X
- |
-
-A type that is a model of LessThanComparable
- |
-
-
-
-x, y, z
- |
-
-Object of type X
- |
-
-
-Definitions
-Consider the relation !(x < y) && !(y < x). If this relation is
-transitive (that is, if !(x < y) && !(y < x) && !(y < z) && !(z < y)
-implies !(x < z) && !(z < x)), then it satisfies the mathematical
-definition of an equivalence relation. In this case, operator<
-is a strict weak ordering.
-
-If operator< is a strict weak ordering, and if each equivalence class
-has only a single element, then operator< is a total ordering.
-
Valid expressions
-
-
-
-Name
- |
-
-Expression
- |
-
-Type requirements
- |
-
-Return type
- |
-
-
-
-Less
- |
-
-x < y
- |
-
-
- |
-
-Convertible to bool
- |
-
-
+
+ 
+ LessThanComparable
+ Description
-Expression semantics
-
-
-
-Name
- |
-
-Expression
- |
-
-Precondition
- |
-
-Semantics
- |
-
-Postcondition
- |
-
-
-
-Less
- |
-
-x < y
- |
-
-x and y are in the domain of <
- |
-
-
- |
-
+ A type is LessThanComparable if it is ordered: it must be possible to
+ compare two objects of that type using operator<, and
+ operator< must be a strict weak ordering relation.
+ Refinement of
-Complexity guarantees
-Invariants
-
-
-
-Irreflexivity
- |
-
-x < x must be false.
- |
-
-
-
-Antisymmetry
- |
-
-x < y implies !(y < x) [2]
- |
-
-
-
-Transitivity
- |
-
-x < y and y < z implies x < z [3]
- |
-
-
-Models
-
-Notes
-[1]
-Only operator< is fundamental; the other inequality operators
-are essentially syntactic sugar.
-
[2]
-Antisymmetry is a theorem, not an axiom: it follows from
-irreflexivity and transitivity.
-
[3]
-Because of irreflexivity and transitivity, operator< always
-satisfies the definition of a partial ordering. The definition of
-a strict weak ordering is stricter, and the definition of a
-total ordering is stricter still.
-
See also
-EqualityComparable, StrictWeakOrdering
+ Associated types
+ Notation
+
+
+ X |
-
-
-
+ A type that is a model of LessThanComparable |
+
-
-
+
+ x, y, z |
+
+ Object of type X |
+
+
+
+ Definitions
+
+ Consider the relation !(x < y) && !(y < x). If
+ this relation is transitive (that is, if !(x < y) && !(y
+ < x) && !(y < z) && !(z < y) implies !(x
+ < z) && !(z < x)), then it satisfies the mathematical
+ definition of an equivalence relation. In this case, operator<
+ is a strict weak ordering.
+
+ If operator< is a strict weak ordering, and if each
+ equivalence class has only a single element, then operator< is
+ a total ordering.
+
+ Valid expressions
+
+
+
+ Name |
+
+ Expression |
+
+ Type requirements |
+
+ Return type |
+
+
+
+ Less |
+
+ x < y |
+
+ |
+
+ Convertible to bool |
+
+
+
+ Expression semantics
+
+
+
+ Name |
+
+ Expression |
+
+ Precondition |
+
+ Semantics |
+
+ Postcondition |
+
+
+
+ Less |
+
+ x < y |
+
+ x and y are in the domain of
+ < |
+
+ |
+
+
+
+ Complexity guarantees
+
+ Invariants
+
+
+
+ Irreflexivity |
+
+ x < x must be false. |
+
+
+
+ Antisymmetry |
+
+ x < y implies !(y < x) [2] |
+
+
+
+ Transitivity |
+
+ x < y and y < z implies x
+ < z [3] |
+
+
+
+ Models
+
+
+
+ Notes
+
+ [1] Only operator< is fundamental;
+ the other inequality operators are essentially syntactic sugar.
+
+ [2] Antisymmetry is a theorem, not an axiom: it
+ follows from irreflexivity and transitivity.
+
+ [3] Because of irreflexivity and transitivity,
+ operator< always satisfies the definition of a partial
+ ordering. The definition of a strict weak ordering is stricter,
+ and the definition of a total ordering is stricter still.
+
+ See also
+
+ EqualityComparable,
+ StrictWeakOrdering
+
+
+
+ 
+
+ Revised
+ 05
+ December, 2006
+
+
+
+ Distributed under the Boost Software License, Version 1.0. (See
+ accompanying file LICENSE_1_0.txt or
+ copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
diff --git a/MultiPassInputIterator.html b/MultiPassInputIterator.html
index dec6e31..fa7517c 100644
--- a/MultiPassInputIterator.html
+++ b/MultiPassInputIterator.html
@@ -1,92 +1,95 @@
-
-
-
-MultiPassInputIterator
-
-
+
-
+
+
+
+
-
-
-Multi-Pass Input Iterator
-
+ MultiPassInputIterator
+
-This concept is a refinement of Input Iterator,
-adding the requirements that the iterator can be used to make multiple
-passes through a range, and that if it1 == it2 and
-it1 is dereferenceable then ++it1 == ++it2. The
-Multi-Pass Input Iterator is very similar to the Forward Iterator. The
-only difference is that a Forward Iterator
-requires the reference type to be value_type&, whereas
-MultiPassInputIterator is like Input Iterator
-in that the reference type merely has to be convertible to
-value_type.
+
+ 
+ Multi-Pass Input Iterator
-Design Notes
+ This concept is a refinement of Input Iterator, adding
+ the requirements that the iterator can be used to make multiple passes
+ through a range, and that if it1 == it2 and it1 is
+ dereferenceable then ++it1 == ++it2. The Multi-Pass Input Iterator
+ is very similar to the Forward Iterator.
+ The only difference is that a Forward Iterator
+ requires the reference type to be value_type&,
+ whereas MultiPassInputIterator is like Input Iterator in that
+ the reference type merely has to be convertible to
+ value_type.
-comments by Valentin Bonnard:
+ Design Notes
- I think that introducing Multi-Pass Input Iterator isn't the right
-solution. Do you also want to define Multi-Pass Bidirectionnal Iterator
-and Multi-Pass Random Access Iterator ? I don't, definitly. It only
-confuses the issue. The problem lies into the existing hierarchy of
-iterators, which mixes movabillity, modifiabillity and lvalue-ness,
-and these are clearly independant.
+
comments by Valentin Bonnard:
- The terms Forward, Bidirectionnal and Random Access are about
-movabillity and shouldn't be used to mean anything else. In a
-completly orthogonal way, iterators can be immutable, mutable, or
-neither. Lvalueness of iterators is also orthogonal with
-immutabillity. With these clean concepts, your Multi-Pass Input Iterator
-is just called a Forward Iterator.
+
I think that introducing Multi-Pass Input Iterator isn't the right
+ solution. Do you also want to define Multi-Pass Bidirectionnal Iterator and
+ Multi-Pass Random Access Iterator ? I don't, definitly. It only confuses
+ the issue. The problem lies into the existing hierarchy of iterators, which
+ mixes movabillity, modifiabillity and lvalue-ness, and these are clearly
+ independant.
-
-Other translations are:
-std::Forward Iterator -> ForwardIterator & Lvalue Iterator
-std::Bidirectionnal Iterator -> Bidirectionnal Iterator & Lvalue Iterator
-std::Random Access Iterator -> Random Access Iterator & Lvalue Iterator
+
The terms Forward, Bidirectionnal and Random Access are about
+ movabillity and shouldn't be used to mean anything else. In a completly
+ orthogonal way, iterators can be immutable, mutable, or neither. Lvalueness
+ of iterators is also orthogonal with immutabillity. With these clean
+ concepts, your Multi-Pass Input Iterator is just called a Forward
+ Iterator.
-
-Note that in practice the only operation not allowed on my
-Forward Iterator which is allowed on std::Forward Iterator is
-&*it. I think that &* is rarely needed in generic code.
+
Other translations are:
+ std::Forward Iterator -> ForwardIterator & Lvalue Iterator
+ std::Bidirectionnal Iterator -> Bidirectionnal Iterator & Lvalue
+ Iterator
+ std::Random Access Iterator -> Random Access Iterator & Lvalue
+ Iterator
-
-reply by Jeremy Siek:
+
Note that in practice the only operation not allowed on my Forward
+ Iterator which is allowed on std::Forward Iterator is &*it. I
+ think that &* is rarely needed in generic code.
-
-The above analysis by Valentin is right on. Of course, there is
-the problem with backward compatibility. The current STL implementations
-are based on the old definition of Forward Iterator. The right course
-of action is to get Forward Iterator, etc. changed in the C++ standard.
-Once that is done we can drop Multi-Pass Input Iterator.
+
reply by Jeremy Siek:
+ The above analysis by Valentin is right on. Of course, there is the
+ problem with backward compatibility. The current STL implementations are
+ based on the old definition of Forward Iterator. The right course of action
+ is to get Forward Iterator, etc. changed in the C++ standard. Once that is
+ done we can drop Multi-Pass Input Iterator.
+
-
-
-
+ 
-
-
+ Revised
+ 05
+ December, 2006
+
+
+
+ Distributed under the Boost Software License, Version 1.0. (See
+ accompanying file LICENSE_1_0.txt or
+ copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
diff --git a/assert.html b/assert.html
index 4381ae1..a3dec66 100644
--- a/assert.html
+++ b/assert.html
@@ -48,8 +48,9 @@ void assertion_failed(char const * expr, char const * function, char const * fil
can be included multiple times in a single translation unit. BOOST_ASSERT
will be redefined each time as specified above.