diff --git a/concept_check.htm b/concept_check.htm index 911153b..748abe6 100644 --- a/concept_check.htm +++ b/concept_check.htm @@ -205,7 +205,7 @@ stl_algo.h:1377: no match for `_List_iterator<int,int &,int *> & - In this case, the fundamental error is that std:list::iterator does not model the concept of +href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> RandomAccessIterator. The list iterator is only bidirectional, not fully random access (as would be a vector iterator). Unfortunately, there is nothing in the error message to indicate this to the user. @@ -222,7 +222,7 @@ reasons why this message would be hard to understand.
The first part of the constraints() function includes the requirements that correspond to the refinement relationship -between +between RandomAccessIterator and the concepts which it builds upon: - + BidirectionalIterator and - + LessThanComparable. We could have instead used BOOST_CLASS_REQUIRES and placed these requirements in the class body, however BOOST_CLASS_REQUIRES uses C++ language features that @@ -51,7 +51,7 @@ Next we check that the iterator_category of the iterator is either std::random_access_iterator_tag or a derived class. After that we write out some code that corresponds to the valid expressions of the +href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> RandomAccessIterator concept. Typedefs can also be added to enforce the associated types of the concept. diff --git a/implementation.htm b/implementation.htm index 7e65746..ac75fb0 100644 --- a/implementation.htm +++ b/implementation.htm @@ -98,7 +98,7 @@ function named function_requires(). The following code snippet shows how to use function_requires() to make sure that the iterator is a +href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> RandomAccessIterator.
diff --git a/prog_with_concepts.htm b/prog_with_concepts.htm index afd8746..ed1fe5f 100644 --- a/prog_with_concepts.htm +++ b/prog_with_concepts.htm @@ -62,7 +62,7 @@ in the concept. For example, the std::stable_sort() function requires that the value type of the iterator be +href="http://www.sgi.com/tech/stl/LessThanComparable.html"> LessThanComparable, which not only includes operator<(), but also operator>(), operator<=(), and operator>=(). @@ -70,19 +70,19 @@ It turns out that std::stable_sort() only uses operator<(). The question then arises: should std::stable_sort() be specified in terms of the concept +href="http://www.sgi.com/tech/stl/LessThanComparable.html"> LessThanComparable or in terms of a concept that only requires operator<()?We remark first that the use of +href="http://www.sgi.com/tech/stl/LessThanComparable.html"> LessThanComparable does not really violate the requirement minimization principle because all of the other operators can be trivially implemented in terms of operator<(). By ``trivial'' we mean one line of code and a constant run-time cost. More fundamentally, however, the use of +href="http://www.sgi.com/tech/stl/LessThanComparable.html"> LessThanComparable does not violate the requirement minimization principle because all of the comparison operators (<, >, <=, >=) are conceptually equivalent (in @@ -100,7 +100,7 @@ implementation in places to use operator>() instead of requirements are part of the public interface, such a change could potentially break client code. If instead +href="http://www.sgi.com/tech/stl/LessThanComparable.html"> LessThanComparable is given as the requirement for std::stable_sort(), then the maintainer is given a reasonable amount of flexibility within which to work. @@ -113,10 +113,10 @@ semantics of the problem domain being represented. In the problem domain of basic containers, requiring traversal in a single direction is a smaller requirement than requiring traversal in both directions (hence the distinction between +href="http://www.sgi.com/tech/stl/ForwardIterator.html"> ForwardIterator and +href="http://www.sgi.com/tech/stl/BidirectionalIterator.html"> BidirectionalIterator). The semantic difference can be easily seen in the difference between the set of concrete data structures that have forward iterators versus the set that has bidirectional diff --git a/reference.htm b/reference.htm index c8ba256..99f0ca5 100644 --- a/reference.htm +++ b/reference.htm @@ -72,54 +72,54 @@ struct AssignableConcept; // Standard ref 23.1 template <class T> - struct SGIAssignableConcept; + struct SGIAssignableConcept; template <class T> struct DefaultConstructibleConcept; + href="http://www.sgi.com/tech/stl/DefaultConstructible.html">DefaultConstructibleConcept; template <class T> struct CopyConstructibleConcept; // Standard ref 20.1.3 template <class T> - struct EqualityComparableConcept; // Standard ref 20.1.1 + struct EqualityComparableConcept; // Standard ref 20.1.1 template <class T> struct LessThanComparableConcept; // Standard ref 20.1.2 template <class T> - struct ComparableConcept; // The SGI STL LessThanComparable concept + struct ComparableConcept; // The SGI STL LessThanComparable concept
template <class Iter> - struct TrivialIteratorConcept; + struct TrivialIteratorConcept; template <class Iter> struct Mutable_TrivialIteratorConcept; template <class Iter> - struct InputIteratorConcept; // Standard ref 24.1.1 Table 72 + struct InputIteratorConcept; // Standard ref 24.1.1 Table 72 template <class Iter, class T> - struct OutputIteratorConcept; // Standard ref 24.1.2 Table 73 + struct OutputIteratorConcept; // Standard ref 24.1.2 Table 73 template <class Iter> - struct ForwardIteratorConcept; // Standard ref 24.1.3 Table 74 + struct ForwardIteratorConcept; // Standard ref 24.1.3 Table 74 template <class Iter> struct Mutable_ForwardIteratorConcept; template <class Iter> - struct BidirectionalIteratorConcept; // Standard ref 24.1.4 Table 75 + struct BidirectionalIteratorConcept; // Standard ref 24.1.4 Table 75 template <class Iter> struct Mutable_BidirectionalIteratorConcept; template <class Iter> - struct RandomAccessIteratorConcept; // Standard ref 24.1.5 Table 76 + struct RandomAccessIteratorConcept; // Standard ref 24.1.5 Table 76 template <class Iter> struct Mutable_RandomAccessIteratorConcept; @@ -129,77 +129,93 @@template <class Func, class Return> - struct GeneratorConcept; + struct GeneratorConcept; template <class Func, class Return, class Arg> - struct UnaryFunctionConcept; + struct UnaryFunctionConcept; template <class Func, class Return, class First, class Second> - struct BinaryFunctionConcept; + struct BinaryFunctionConcept; template <class Func, class Arg> - struct UnaryPredicateConcept; + struct UnaryPredicateConcept; template <class Func, class First, class Second> - struct BinaryPredicateConcept; + struct BinaryPredicateConcept; template <class Func, class First, class Second> struct Const_BinaryPredicateConcept; + + template <class Func, class Return> + struct AdaptableGeneratorConcept; + + template <class Func, class Return, class Arg> + struct AdaptableUnaryFunctionConcept; + + template <class Func, class First, class Second> + struct AdaptableBinaryFunctionConcept; + + template <class Func, class Arg> + struct AdaptablePredicateConcept; + + template <class Func, class First, class Second> + struct AdaptableBinaryPredicateConcept; +Container Concept Checking Classes
template <class C> - struct ContainerConcept; // Standard ref 23.1 Table 65 + struct ContainerConcept; // Standard ref 23.1 Table 65 template <class C> struct Mutable_ContainerConcept; template <class C> - struct ForwardContainerConcept; + struct ForwardContainerConcept; template <class C> struct Mutable_ForwardContainerConcept; template <class C> - struct ReversibleContainerConcept; // Standard ref 23.1 Table 66 + struct ReversibleContainerConcept; // Standard ref 23.1 Table 66 template <class C> struct Mutable_ReversibleContainerConcept; template <class C> - struct RandomAccessContainerConcept; + struct RandomAccessContainerConcept; template <class C> struct Mutable_RandomAccessContainerConcept; template <class C> - struct SequenceConcept; // Standard ref 23.1.1 + struct SequenceConcept; // Standard ref 23.1.1 template <class C> - struct FrontInsertionSequenceConcept; + struct FrontInsertionSequenceConcept; template <class C> - struct BackInsertionSequenceConcept; + struct BackInsertionSequenceConcept; template <class C> - struct AssociativeContainerConcept; // Standard ref 23.1.2 Table 69 + struct AssociativeContainerConcept; // Standard ref 23.1.2 Table 69 template <class C> - struct UniqueAssociativeContainerConcept; + struct UniqueAssociativeContainerConcept; template <class C> - struct MultipleAssociativeContainerConcept; + struct MultipleAssociativeContainerConcept; template <class C> - struct SimpleAssociativeContainerConcept; + struct SimpleAssociativeContainerConcept; template <class C> - struct PairAssociativeContainerConcept; + struct PairAssociativeContainerConcept; template <class C> - struct SortedAssociativeContainerConcept; + struct SortedAssociativeContainerConcept;diff --git a/using_concept_check.htm b/using_concept_check.htm index ef9ea3b..1bf670c 100644 --- a/using_concept_check.htm +++ b/using_concept_check.htm @@ -43,7 +43,7 @@ An example of a concept checking class from the BCCL is the EqualityComparableConcept class. The class corresponds to the EqualityComparable requirements described in 20.1.1 of the C++ Standard, and to the EqualityComparable +href="http://www.sgi.com/tech/stl/EqualityComparable.html">EqualityComparable concept documented in the SGI STL.@@ -132,10 +132,10 @@ href="./concept_check.htm#motivating-example">motivating example, one good applicatino of concept checks would be to insert function_requires() at the top of std::stable_sort() to make sure the template parameter type models +href="http://www.sgi.com/tech/stl/RandomAccessIterator.html"> RandomAccessIterator. In addition, std::stable_sort() requires that the value_type of the iterators be - + LessThanComparable, so we also use function_requires() to check this. @@ -182,7 +182,7 @@ type for the map. As an example of using BOOST_CLASS_REQUIRES we look at a concept check that could be added to std::vector. One requirement that is placed on the element type is that it must be Assignable. +href="http://www.sgi.com/tech/stl/Assignable.html">Assignable. We can check this by inserting class_requires<AssignableConcept<T> > at the top of the definition for std::vector.