diff --git a/Assignable.html b/Assignable.html index 557f4e7..54934f1 100644 --- a/Assignable.html +++ b/Assignable.html @@ -1,116 +1,109 @@ - - - -Assignable - - -C++ Boost - -
-

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

- - - - - + + C++ Boost
- - - - +

Assignable

- - - - +

Description

-
-T - -is type that is a model of Assignable -
-t - -is an object of type T -
-u - -is an object of type T or possibly const T -
-

Definitions

-

Valid expressions

- - - - - - - - - - - - - +

A type is Assignable if it is possible to assign one object of the type + to another object of that type.

-
-Name - -Expression - -Return type - -Semantics -
-Assignment - -t = u - -T& - -t is equivalent to u -
+

Notation

+ + + -
T
-

Models

+ is type that is a model of Assignable + - + + t -

See also

-DefaultConstructible -and -CopyConstructible + is an object of type T + -
-
- - -
Copyright © 2000 -Jeremy Siek, Univ.of Notre Dame (jsiek@lsc.nd.edu) -
+ + u - - + is an object of type T or possibly const + T + + + +

Definitions

+ +

Valid expressions

+ + + + + + + + + + + + + + + + + + + + + +
NameExpressionReturn typeSemantics
Assignmentt = uT&t is equivalent to u
+ +

Models

+ + + +

See also

+ +

DefaultConstructible + and CopyConstructible

+
+ +

Valid HTML 4.01 Transitional

+ +

Revised + 05 December, 2006

+ + + + + + + +
Copyright © 2000Jeremy Siek, Univ.of + Notre Dame (jsiek@lsc.nd.edu)
+ +

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 - + - -

- boost logo -
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: + +

boost logo
+ Collection

- +

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. + 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

+ + + -The following expressions must be valid. -

+

-
Value typeX::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

- + 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

-

+

-

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
- -
Copyright © 2000 -Jeremy Siek, Univ.of Notre Dame and C++ Library & Compiler Group/SGI (jsiek@engr.sgi.com) -
+ 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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameExpressionReturn typeSemantics
Beginning of rangea.rbegin()reverse_iterator if a is mutable, + const_reverse_iterator otherwise.Equivalent to + X::reverse_iterator(a.end()).
End of rangea.rend()reverse_iterator if a is mutable, + const_reverse_iterator otherwise.Equivalent to + X::reverse_iterator(a.begin()).
Backa.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.

+ + + + + + + + + + + + + + + + + + + + + +
NameExpressionReturn typeSemantics
Element Accessa[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

+
+ +

Valid HTML 4.01 Transitional

+ +

Revised + 05 + December, 2006

+ + + + + + + +
Copyright © 2000Jeremy + Siek, Univ.of Notre Dame and C++ Library & Compiler Group/SGI + (jsiek@engr.sgi.com)
+ +

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 - - -C++ Boost - -
-

Copy Constructible

+ -

Description

-A type is Copy Constructible if it is possible to copy objects of that -type. + + + + -

Notation

- - - - - + Copy Constructible + - - - - + + C++ Boost
- - - - +

Copy Constructible

-
-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

- - - - - - - - - - - - - +

Description

+

A type is Copy Constructible if it is possible to copy objects of that + type.

- - -
-Name - -Expression - -Return type - -Semantics -
-Copy constructor - -T(t) - -T - -t is equivalent to T(t) -
-Copy constructor - -
+  
Notation

+
+  
+    
+      
+
+      
+    
+
+    
+      
+
+      
+    
+
+    
+      
+
+      
+    
+  
Tis type that is a model of Copy Constructible
tis an object of type T
uis an object of type const T

+
+  
Definitions

+
+  
Valid expressions

+
+  
+    
+      
+
+      
+
+      
+
+      
+    
+
+    
+      
+
+      
+
+      
+
+      
+    
+
+    
+      
+
+      
-
-
-
+      
 
+      
 
-
-
-
+    
+
+    
+      
+
+      
-
-
-
+      
 
-
-
-
+
+      
+    
+
+    
+      
+
+      
-
-
-
+      
 
-
-
-
+
+      
+    
+
+    
+      
+
+      
-
-
-
+      
 
+      
 
+      
+    
+  
NameExpressionReturn typeSemantics
Copy constructorT(t)Tt 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

+ - - -

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

 
-

-

-
-
-
Copyright © 2000
-Jeremy Siek, Univ.of Notre Dame (jsiek@lsc.nd.edu)
-

+  
Default
+  Constructible and Assignable

+  

 
-
- 
+  
Valid HTML 4.01 Transitional

+
+  
Revised 
+  05
+  December, 2006

+
+  
+    
+      
+
+      
+    
+  
Copyright © 2000Jeremy Siek, Univ.of
+      Notre Dame (jsiek@lsc.nd.edu)

+
+  
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
-
- 
-C++ Boost 
-
-

-
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
-

+
+  C++ Boost

 
+  
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

-
-
Copyright © 2000
-Jeremy Siek, Univ.of Notre Dame (jsiek@lsc.nd.edu)
-

+      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

+
+  
+    
+      
+
+      
+
+      
+
+      
+    
+
+    
+      
+
+      
+
+      
+
+      
+    
+  
NameExpressionType requirementsReturn type
Lessx < y Convertible to bool

+
+  
Expression semantics

+
+  
+    
+      
+
+      
+
+      
+
+      
+
+      
+    
+
+    
+      
+
+      
+
+      
+
+      
+    
+  
NameExpressionPreconditionSemanticsPostcondition
Lessx < yx and y are in the domain of
+      < 

+
+  
Complexity guarantees

+
+  
Invariants

+
+  
+    
+      
+
+      
+    
+
+    
+      
+
+      
+    
+
+    
+      
+
+      
+    
+  
Irreflexivityx < x must be false.
Antisymmetryx < y implies !(y < x) [2]
Transitivityx < 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

+  

+  

+
+  
Valid HTML 4.01 Transitional

+
+  
Revised 
+  05
+  December, 2006

+
+  
+    
+      
+
+      
+    
+  
Copyright © 2000Jeremy Siek, Univ.of
+      Notre Dame (jsiek@lsc.nd.edu)

+
+  
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
- 
-C++ Boost 
+
 
-

+
+
+  
+  
 
-

-
-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.
+
+  C++ Boost

 
+  
 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.

+  

 
-

-

-
-
-
Copyright © 2000
-Jeremy Siek, Univ.of Notre Dame (jsiek@lsc.nd.edu)
-

+  
Valid HTML 4.01 Transitional

 
-
- 
+  
Revised 
+  05
+  December, 2006

+
+  
+    
+      
+
+      
+    
+  
Copyright © 2000Jeremy Siek, Univ.of
+      Notre Dame (jsiek@lsc.nd.edu)

+
+  
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/generator_iterator.htm b/generator_iterator.htm
index fd3e3fc..c81d3d1 100644
--- a/generator_iterator.htm
+++ b/generator_iterator.htm
@@ -1,33 +1,37 @@
-
+
 
 
 
-Generator Iterator Adaptor Documentation
+  
+  
+
+  Generator Iterator Adaptor Documentation
 
 
 
-        
-boost.png (6897 bytes) 
+  boost.png (6897 bytes)
 
-
Generator Iterator Adaptor

-Defined in header boost/generator_iterator.hpp 
-

-The generator iterator adaptor makes it easier to create custom input
-iterators from 0-ary functions and function objects.  The adaptor
-takes a
-Generator
-and creates a model of
-Input Iterator.
-Each increment retrieves an item from the generator and makes it
-available to be retrieved by dereferencing.  The motivation for this
-iterator is that some concepts can be more naturally expressed as a
-generator, while most STL algorithms expect an iterator.  An example
-is the Random Number library.
+  
Generator Iterator Adaptor

 
-
Synopsis

+  
Defined in header boost/generator_iterator.hpp

 
-

-
+  
The generator iterator adaptor makes it easier to create custom input
+  iterators from 0-ary functions and function objects. The adaptor takes a
+  Generator and
+  creates a model of Input Iterator. Each
+  increment retrieves an item from the generator and makes it available to be
+  retrieved by dereferencing. The motivation for this iterator is that some
+  concepts can be more naturally expressed as a generator, while most STL
+  algorithms expect an iterator. An example is the Random Number library.

+
+  
Synopsis

+
+  

+    
 namespace boost {
   template <class Generator>
   class generator_iterator_policies;
@@ -40,21 +44,19 @@ namespace boost {
   make_generator_iterator(Generator & gen);
 }
 

-

+  

+  

 
-

+  
The Generator Iterator Generator Class

 
-
The Generator Iterator Generator Class

-
-The class generator_iterator_generator is a helper class whose purpose
-is to construct a generator iterator type. The template parameter for
-this class is the Generator function object type that is being
-wrapped.  The generator iterator adaptor only holds a reference (or
-pointer) to the function object, therefore the function object must
-outlive the generator iterator adaptor constructed from it.
-
-
-template <class Generator>
+  
The class generator_iterator_generator is a helper class whose purpose
+  is to construct a generator iterator type. The template parameter for this
+  class is the Generator function object type that is being wrapped. The
+  generator iterator adaptor only holds a reference (or pointer) to the
+  function object, therefore the function object must outlive the generator
+  iterator adaptor constructed from it.

+  
+template <class Generator>
 class generator_iterator_generator
 {
 public:
@@ -62,65 +64,65 @@ public:
 }
 

 
+  
Template Parameters

 
-
Template Parameters

+  
+    
+      
 
-
Parameter

-
-
-
-
+      
+    
 
-
-
-
ParameterDescription
Description
Generator 
-The generator (0-ary function object) type being
-wrapped.  The return type of the function must be defined as
-Generator::result_type.  The function object must be a model
-of
-Generator.
-

+    
+      Generator
 
-
Concept Model

-The generator iterator class is a model of
-Input Iterator.
+      The generator (0-ary function object) type being wrapped. The
+      return type of the function must be defined as
+      Generator::result_type. The function object must be a model of
+      Generator.
+    
+  
 
-
Members

-The generator iterator implements the member functions
-and operators required of the
-Input Iterator
-concept.
+  
Concept Model

 
-

+  
The generator iterator class is a model of Input Iterator.

 
-

-
The Generator Iterator Object Generator

+  
Members

 
-The make_generator_iterator() function provides a
-convenient way to create generator iterator objects. The function
-saves the user the trouble of explicitly writing out the iterator
-types.
+  
The generator iterator implements the member functions and operators
+  required of the Input Iterator
+  concept.

+  

 
-

-
+  
The
+  Generator Iterator Object Generator

+
+  
The make_generator_iterator() function provides a convenient
+  way to create generator iterator objects. The function saves the user the
+  trouble of explicitly writing out the iterator types.

+
+  

+    
 template <class Generator>
 typename generator_iterator_generator<Generator>::type
 make_generator_iterator(Generator & gen);
 

-

+  

+  

 
-

+  
Example

 
+  
The following program shows how generator_iterator
+  transforms a generator into an input iterator.

 
-
Example

-
-The following program shows how generator_iterator
-transforms a generator into an input iterator.
-
-

-
-#include <iostream>
-#include <boost/generator_iterator.hpp>
+  

+    
+#include <iostream>
+#include <boost/generator_iterator.hpp>
 
 class my_generator
 {
@@ -140,11 +142,22 @@ int main()
     std::cout << *it << std::endl;
 }
 

-

+  

+  

 
-

+  
Valid HTML 4.01 Transitional

 
-Written by Jens Maurer.
+  
Revised 
+  05 December, 2006

 
+  
Copyright © 2001 Jens Maurer

+
+  
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)