feedc0de/boost_iterator
1
0
Fork 0
forked from boostorg/iterator
Code Pull Requests Activity

ReST-ified

Browse Source 
[SVN r21467]
This commit is contained in:
Dave Abrahams
2004-01-03 21:55:25 +00:00
parent d5e525dd19
commit e9bb297ed2
1 changed files with 482 additions and 349 deletions
Download Patch File Download Diff File Expand all files Collapse all files

535
doc/iter-issue-list.rst
View File

@@ -1,23 +1,43 @@
9 Iterator concept and adapter issues +++++++++++++++++++++++++++++++++++++
Iterator concept and adapter issues
+++++++++++++++++++++++++++++++++++++
:date: $Date$
:copyright: Copyright David Abrahams, Jeremy Siek, and Thomas Witt 2003.
===================================
Issues from Matt's TR issues list
===================================
.. contents:: Index
9.1 iterator_access overspecified? 9.1 iterator_access overspecified?
Submitter: Pete Becker ==================================
Status: New
The proposal includes: :Submitter: Pete Becker
enum iterator_access { readable_iterator = 1, writable_iterator = 2, swappable_iterator = 4, :Status: New
lvalue_iterator = 8 };
The proposal includes::
enum iterator_access {
readable_iterator = 1, writable_iterator = 2,
swappable_iterator = 4, lvalue_iterator = 8
};
In general, the standard specifies thing like this as a bitmask type with a list of defined names, In general, the standard specifies thing like this as a bitmask type with a list of defined names,
and specifies neither the exact type nor the specific values. Is there a reason for iterator_access to and specifies neither the exact type nor the specific values. Is there a reason for iterator_access to
be more specific? be more specific?
Proposed resolution: :Proposed resolution: The iterator_access enum will be removed, so
The iterator_access enum will be removed, so this is no longer an this is no longer an issue. See the resolution to 9.15.
issue. See the resolution to 9.15.
9.2 operators of iterator_facade overspecified 9.2 operators of iterator_facade overspecified
Submitter: Pete Becker ==============================================
Status: New
:Submitter: Pete Becker
:Status: New
In general, we've provided operational semantics for things like operator++. That is, we've said In general, we've provided operational semantics for things like operator++. That is, we've said
that ++iter must work, without requiring either a member function or a non-member function. that ++iter must work, without requiring either a member function or a non-member function.
iterator_facade specifies most operators as member functions. There's no inherent reason for iterator_facade specifies most operators as member functions. There's no inherent reason for
@@ -28,41 +48,50 @@ operator++(int), operator--(), operator--(int), operator+=, operator-=, operator
operator-(iterator_facade instance), and operator+ should be specified with operational semantics operator-(iterator_facade instance), and operator+ should be specified with operational semantics
and not explicitly required to be members or non-members. and not explicitly required to be members or non-members.
Proposed resolution: :Proposed resolution: Not a defect.
Not a defect.
Rationale: :Rationale: We are following the approach in the standard. Classes
We are following the approach in the standard. Classes such such as reverse_iterator are specified by listing the function
as reverse_iterator are specified by listing the function prototypes prototypes for the various operators. Further, the prototype
for the various operators. Further, the prototype specification does specification does not prevent the implementor from using members
not prevent the implementor from using members or non-members. or non-members.
9.3 enable_if_interoperable needs standardese 9.3 enable_if_interoperable needs standardese
Submitter: Pete Becker =============================================
Status: New
:Submitter: Pete Becker
:Status: New
The only discussion of what this means is in a note, so is non-normative. Further, the note seems The only discussion of what this means is in a note, so is non-normative. Further, the note seems
to be incorrect. It says that enable_if_interoperable only works for types that "are to be incorrect. It says that enable_if_interoperable only works for types that "are
interoperable, by which we mean they are convertible to each other." This requirement is too interoperable, by which we mean they are convertible to each other." This requirement is too
strong: it should be that one of the types is convertible to the other. strong: it should be that one of the types is convertible to the other.
N1541 48 N1541 48
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work**
Remove the enable_if_interoperable stuff, and just write all the comparisons to return bool. Then Remove the enable_if_interoperable stuff, and just write all the comparisons to return bool. Then
add a blanket statement that the behavior of these functions is undefined if the two types aren't add a blanket statement that the behavior of these functions is undefined if the two types aren't
interoperable. interoperable.
9.4 enable_if_convertible unspecified, conflicts with requires 9.4 enable_if_convertible unspecified, conflicts with requires
Submitter: Pete Becker ==============================================================
Status: New
In every place where enable_if_convertible is used it's used like this (simplified): :Submitter: Pete Becker
:Status: New
In every place where enable_if_convertible is used it's used like
this (simplified)::
template<class T> template<class T>
struct C struct C
{ {
template<class T1> template<class T1>
C(T1, enable_if_convertible<T1, T>::type* = 0); C(T1, enable_if_convertible<T1, T>::type* = 0);
}; };
The idea being that this constructor won't compile if T1 isn't convertible to T. As a result, the The idea being that this constructor won't compile if T1 isn't convertible to T. As a result, the
constructor won't be considered as a possible overload when constructing from an object x where constructor won't be considered as a possible overload when constructing from an object x where
the type of x isn't convertible to T. In addition, however, each of these constructors has a requires the type of x isn't convertible to T. In addition, however, each of these constructors has a requires
@@ -85,134 +114,165 @@ There was more discussion on the reflector: c++std-lib-12312, c++std-lib-12325,
12330, c++std-lib-12334, c++std-lib-12335, c++std-lib-12336, c++std-lib-12338, c++std-lib- 12330, c++std-lib-12334, c++std-lib-12335, c++std-lib-12336, c++std-lib-12338, c++std-lib-
12362. 12362.
Proposed resolution: :Proposed resolution: Specify enable_if_convertible to be as-if
Specify enable_if_convertible to be as-if: ::
template <bool> enable_if_convertible_impl template <bool> enable_if_convertible_impl
{}; {};
N1541 49
template <> enable_if_convertible_impl<true> template <> enable_if_convertible_impl<true>
{ struct type; }; { struct type; };
template<typename From, typename To> template<typename From, typename To>
struct enable_if_convertible struct enable_if_convertible
: enable_if_convertible_impl< : enable_if_convertible_impl<
is_convertible<From, To>::value is_convertible<From, To>::value>
{}; {};
9.5 iterator_adaptor has an extraneous 'bool' at the start of the 9.5 iterator_adaptor has an extraneous 'bool' at the start of the template definition
template definition =====================================================================================
Submitter: Pete Becker
Status: New :Submitter: Pete Becker
:Status: New
The title says it all; this is probably just a typo. The title says it all; this is probably just a typo.
Proposed resolution: :Proposed resolution: Remove the 'bool'.
Remove the 'bool'.
9.6 Name of private member shouldn't be normative 9.6 Name of private member shouldn't be normative
Submitter: Pete Becker =================================================
Status: New
:Submitter: Pete Becker
:Status: New
iterator_adaptor has a private member named m_iterator. Presumably this is for exposition only, iterator_adaptor has a private member named m_iterator. Presumably this is for exposition only,
since it's an implementation detail. It needs to be marked as such. since it's an implementation detail. It needs to be marked as such.
Proposed resolution: :Proposed resolution: Mark the member m_iterator as exposition only.
Mark the member m_iterator as exposition only.
9.7 iterator_adaptor operations specifications are a bit inconsistent 9.7 iterator_adaptor operations specifications are a bit inconsistent
Submitter: Pete Becker =====================================================================
Status: New
:Submitter: Pete Becker
:Status: New
iterator_adpator() has a Requires clause, that Base must be default constructible. iterator_adpator() has a Requires clause, that Base must be default constructible.
iterator_adaptor(Base) has no Requires clause, although the Returns clause says that the Base iterator_adaptor(Base) has no Requires clause, although the Returns clause says that the Base
member is copy construced from the argument (this may actually be an oversight in N1550, member is copy construced from the argument (this may actually be an oversight in N1550,
which doesn't require iterators to be copy constructible or assignable). which doesn't require iterators to be copy constructible or assignable).
Proposed resolution: **** Needs work **** (Jeremy) :Proposed resolution: **Needs work** (Jeremy)
Add a requirements section for the template parameters of Add a requirements section for the template parameters of
iterator_adaptor, and state that Base must be Copy Constructible and iterator_adaptor, and state that Base must be Copy Constructible and
Assignable. Assignable.
9.8 Specialized adaptors text should be normative 9.8 Specialized adaptors text should be normative
Submitter: Pete Becker =================================================
Status: New
:Submitter: Pete Becker
:Status: New
similar to 9.3, "Specialized Adaptors" has a note describing enable_if_convertible. This should similar to 9.3, "Specialized Adaptors" has a note describing enable_if_convertible. This should
be normative text. be normative text.
Proposed resolution: :Proposed resolution: **Needs work**
Change it to normative text. Change it to normative text.
9.9 Reverse_iterator text is too informal 9.9 Reverse_iterator text is too informal
Submitter: Pete Becker =========================================
Status: New
:Submitter: Pete Becker
:Status: New
reverse iterator "flips the direction of the base iterator's motion". This needs to be more formal, reverse iterator "flips the direction of the base iterator's motion". This needs to be more formal,
as in the current standard. Something like: "iterates through the controlled sequence in the as in the current standard. Something like: "iterates through the controlled sequence in the
opposite direction" opposite direction"
N1541 50
Proposed resolution: **** Needs work **** (Jeremy) :Proposed resolution: **Needs work** (Jeremy)
We agree and need to find wording. We agree and need to find wording.
9.10 'prior' is undefined 9.10 'prior' is undefined
Submitter: Pete Becker =========================
Status: New
:Submitter: Pete Becker
:Status: New
reverse_iterator::dereference is specified as calling a function named 'prior' which has no reverse_iterator::dereference is specified as calling a function named 'prior' which has no
specification. specification.
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)
Replace use of prior with what it does. Replace use of prior with what it does.
9.11 "In other words" is bad wording 9.11 "In other words" is bad wording
Submitter: Pete Becker ====================================
Status: New
:Submitter: Pete Becker
:Status: New
Transform iterator has a two-part specification: it does this, in other words, it does that. "In other Transform iterator has a two-part specification: it does this, in other words, it does that. "In other
words" always means "I didn't say it right, so I'll try again." We need to say it once. words" always means "I didn't say it right, so I'll try again." We need to say it once.
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)
Reword. Reword.
9.12 Transform_iterator shouldn’t mandate private member 9.12 Transform_iterator shouldn<EFBFBD>t mandate private member
Submitter: Pete Becker ========================================================
Status: New
:Submitter: Pete Becker
:Status: New
transform_iterator has a private member named 'm_f' which should be marked "exposition only." transform_iterator has a private member named 'm_f' which should be marked "exposition only."
Proposed resolution: :Proposed resolution: Mark the member m_f as exposition only.
Mark the member m_f as exposition only.
9.13 Unclear description of counting iterator 9.13 Unclear description of counting iterator
Submitter: Pete Becker =============================================
Status: New
:Submitter: Pete Becker
:Status: New
The description of Counting iterator is unclear. "The counting iterator adaptor implements The description of Counting iterator is unclear. "The counting iterator adaptor implements
dereference by returning a reference to the base object. The other operations are implemented by dereference by returning a reference to the base object. The other operations are implemented by
the base m_iterator, as per the inheritance from iterator_adaptor." the base m_iterator, as per the inheritance from iterator_adaptor."
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy) Reword.
Reword.
9.14 Counting_iterator's difference type 9.14 Counting_iterator's difference type
Submitter: Pete Becker ========================================
Status: New :Submitter: Pete Becker
:Status: New
Counting iterator has the following note: Counting iterator has the following note:
[Note: implementers are encouraged to provide an implementation of distance_to and a
difference_type that avoids overflows in the cases when the Incrementable type is a numeric [Note: implementers are encouraged to provide an implementation
type.] of distance_to and a difference_type that avoids overflows in the
cases when the Incrementable type is a numeric type.]
I'm not sure what this means. The user provides a template argument named Difference, but I'm not sure what this means. The user provides a template argument named Difference, but
there's no difference_type. I assume this is just a glitch in the wording. But if implementors are there's no difference_type. I assume this is just a glitch in the wording. But if implementors are
encouraged to ignore this argument if it won't work right, why is it there? encouraged to ignore this argument if it won't work right, why is it there?
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)
Reword. Reword.
9.15 How to detect lvalueness? 9.15 How to detect lvalueness?
Submitter: Dave Abrahams ==============================
Status: New
:Submitter: Dave Abrahams
:Status: New
Shortly after N1550 was accepted, we discovered that an iterator's lvalueness can be determined Shortly after N1550 was accepted, we discovered that an iterator's lvalueness can be determined
knowing only itsvalue_type. This predicate can be calculated even for old-style iterators (on knowing only itsvalue_type. This predicate can be calculated even for old-style iterators (on
N1541 51 N1541 51
@@ -224,7 +284,8 @@ Thus, any interface which asks the user to explicitly describe an iterator's lva
readability seems to introduce needless complexity. readability seems to introduce needless complexity.
Proposed resolution: :Proposed resolution:
1. Remove the ``is_writable`` and ``is_swappable`` traits, and remove the 1. Remove the ``is_writable`` and ``is_swappable`` traits, and remove the
requirements in the Writable Iterator and Swappable Iterator concepts requirements in the Writable Iterator and Swappable Iterator concepts
that require their models to support these traits. that require their models to support these traits.
@@ -262,7 +323,8 @@ Proposed resolution:
else else
return null_category_tag; return null_category_tag;
Rationale: :Rationale:
1. There are two reasons for removing ``is_writable`` 1. There are two reasons for removing ``is_writable``
and ``is_swappable``. The first is that we do not know of and ``is_swappable``. The first is that we do not know of
a way to fix the specification so that it gives the correct a way to fix the specification so that it gives the correct
@@ -305,8 +367,11 @@ Rationale:
9.16 is_writable_iterator returns false positives 9.16 is_writable_iterator returns false positives
Submitter: Dave Abrahams =================================================
Status: New
:Submitter: Dave Abrahams
:Status: New
is_writable_iterator returns false positives for forward iterators whose value_type has a private is_writable_iterator returns false positives for forward iterators whose value_type has a private
assignment operator, or whose reference type is not a reference (currently legal). assignment operator, or whose reference type is not a reference (currently legal).
@@ -315,8 +380,8 @@ See the resolution to 9.15.
9.17 is_swappable_iterator returns false positives 9.17 is_swappable_iterator returns false positives
Submitter: Dave Abrahams :Submitter: Dave Abrahams
Status: New :Status: New
is_swappable_iterator has the same problems as is_writable_iterator. In addition, if we allow is_swappable_iterator has the same problems as is_writable_iterator. In addition, if we allow
users to write their own iter_swap functions it's easy to imagine old-style iterators for which users to write their own iter_swap functions it's easy to imagine old-style iterators for which
is_swappable returns false negatives. is_swappable returns false negatives.
@@ -326,8 +391,8 @@ See the resolution to 9.15.
9.18 Are is_readable, is_writable, and is_swappable useful? 9.18 Are is_readable, is_writable, and is_swappable useful?
Submitter: Dave Abrahams :Submitter: Dave Abrahams
Status: New :Status: New
I am concerned that there is little use for any of is_readable, is_writable, or is_swappable, and I am concerned that there is little use for any of is_readable, is_writable, or is_swappable, and
that not only do they unduly constrain iterator implementors but they add overhead to that not only do they unduly constrain iterator implementors but they add overhead to
iterator_facade and iterator_adaptor in the form of a template parameter which would otherwise iterator_facade and iterator_adaptor in the form of a template parameter which would otherwise
@@ -339,8 +404,8 @@ See the resolution to 9.15.
9.19 Non-Uniformity of the "lvalue_iterator Bit" 9.19 Non-Uniformity of the "lvalue_iterator Bit"
Submitter: Dave Abrahams :Submitter: Dave Abrahams
Status: New :Status: New
The proposed iterator_tag class template accepts an "access bits" parameter which includes a bit The proposed iterator_tag class template accepts an "access bits" parameter which includes a bit
to indicate the iterator's lvalueness (whether its dereference operator returns a reference to its to indicate the iterator's lvalueness (whether its dereference operator returns a reference to its
value_type. The relevant part of N1550 says: value_type. The relevant part of N1550 says:
@@ -358,8 +423,8 @@ See the resolution to 9.15.
9.20 Traversal Concepts and Tags 9.20 Traversal Concepts and Tags
Submitter: Dave Abrahams :Submitter: Dave Abrahams
Status: New :Status: New
Howard Hinnant pointed out some inconsistencies with the naming of these tag types: Howard Hinnant pointed out some inconsistencies with the naming of these tag types:
incrementable_iterator_tag // ++r, r++ incrementable_iterator_tag // ++r, r++
single_pass_iterator_tag // adds a == b, a != b single_pass_iterator_tag // adds a == b, a != b
@@ -374,8 +439,9 @@ equality comparable. Forward traversal iterators really distinguish themselves b
multi-pass capability. Without entering a "Parkinson's Bicycle Shed" type of discussion, it might multi-pass capability. Without entering a "Parkinson's Bicycle Shed" type of discussion, it might
be worth giving the names of these tags (and the associated concepts) some extra attention. be worth giving the names of these tags (and the associated concepts) some extra attention.
Proposed resolution: :Proposed resolution: Change the names of the traversal tags to the
Change the names of the traversal tags to the following names. following names::
incrementable_traversal_tag incrementable_traversal_tag
single_pass_traversal_tag single_pass_traversal_tag
forward_traversal_tag forward_traversal_tag
@@ -384,8 +450,8 @@ Change the names of the traversal tags to the following names.
9.21 iterator_facade Derived template argument underspecified 9.21 iterator_facade Derived template argument underspecified
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
The first template argument to iterator_facade is named Derived, and the proposal says: The first template argument to iterator_facade is named Derived, and the proposal says:
The Derived template parameter must be a class derived from iterator_facade. The Derived template parameter must be a class derived from iterator_facade.
First, iterator_facade is a template, so cannot be derived from. Rather, the class must be derived First, iterator_facade is a template, so cannot be derived from. Rather, the class must be derived
@@ -399,15 +465,16 @@ like "when using iterator_facade to define an iterator class Iter, the class Ite
from a specialization of iterator_facade whose first template argument is Iter." That's a bit from a specialization of iterator_facade whose first template argument is Iter." That's a bit
awkward, but at the moment I don't see a better way of phrasing it. awkward, but at the moment I don't see a better way of phrasing it.
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work**
Reword. Reword.
9.22 return type of Iterator difference for iterator facade 9.22 return type of Iterator difference for iterator facade
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
N1541 53 N1541 53
The proposal says: The proposal says:
@@ -420,104 +487,119 @@ Shouldn't the return type be one of the two iterator types? Which one? The idea
the iterator types can be converted to the other type, then the subtraction is okay. Seems like the the iterator types can be converted to the other type, then the subtraction is okay. Seems like the
return type should then be the type that was converted to. Is that right? return type should then be the type that was converted to. Is that right?
Proposed resolution: :Proposed resolution:
Change the return type from Change the return type from ::
typename enable_if_interoperable<Dr1, Dr2, bool>::type typename enable_if_interoperable<Dr1, Dr2, bool>::type
to
to ::
typename enable_if_interoperable<Dr1, Dr2, D1>::type typename enable_if_interoperable<Dr1, Dr2, D1>::type
9.23 Iterator_facade: minor wording Issue 9.23 Iterator_facade: minor wording Issue
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
In the table that lists the required (sort of) member functions of iterator types that are based on In the table that lists the required (sort of) member functions of iterator types that are based on
iterator_facade, the entry for c.equal(y) says: iterator_facade, the entry for c.equal(y) says:
true iff c and y refer to the same position. Implements c == y and c != y. true iff c and y refer to the same position. Implements c == y and c != y.
The second sentence is inside out. c.equal(y) does not implement either of these operations. It is The second sentence is inside out. c.equal(y) does not implement either of these operations. It is
used to implement them. Same thing in the description of c.distance_to(z). used to implement them. Same thing in the description of c.distance_to(z).
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work**
Reword. Reword.
9.24 Use of undefined name in iterator_facade table 9.24 Use of undefined name in iterator_facade table
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
Several of the descriptions use the name X without defining it. This seems to be a carryover from Several of the descriptions use the name X without defining it. This seems to be a carryover from
the table immediately above this section, but the text preceding that table says "In the table the table immediately above this section, but the text preceding that table says "In the table
below, X is the derived iterator type." Looks like the X:: qualifiers aren't really needed; below, X is the derived iterator type." Looks like the X:: qualifiers aren't really needed;
X::reference can simply be reference, since that's defined by the iterator_facade specialization X::reference can simply be reference, since that's defined by the iterator_facade specialization
itself. itself.
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work**
Remove the use of X. Remove the use of X.
9.25 Iterator_facade: wrong return type 9.25 Iterator_facade: wrong return type
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
Several of the member functions return a Derived object or a Derived&. Their Effects clauses Several of the member functions return a Derived object or a Derived&. Their Effects clauses
end with: end with:
return *this; return *this;
This should be This should be
return *static_cast<Derived*>(this); return *static_cast<Derived*>(this);
Proposed resolution: :Proposed resolution:
Change the returns clause to Change the returns clause to::
return *static_cast<Derived*>(this); return *static_cast<Derived*>(this);
9.26 Iterator_facade: unclear returns clause for operator[] 9.26 Iterator_facade: unclear returns clause for operator[]
Submitter: Pete Becker :Submitter: Pete Becker
N1541 54 N1541 54
Status: New :Status: New
The returns clause for operator[](difference_type n) const says:
Returns: an object convertible to X::reference and holding a copy p of a+n such that, for a The returns clause for ``operator[](difference_type n)`` const
constant object v of type X::value_type, X::reference(a[n] = v) is equivalent to p = v. says:
This needs to define 'a', but assuming it's supposed to be *this (or maybe *(Derived*)this), it still
isn't clear what this says. Presumably, the idea is that you can index off of an iterator and assign Returns: an object convertible to X::reference and holding a copy
to the result. But why the requirement that it hold a copy of a+n? Granted, that's probably how p of a+n such that, for a constant object v of type
it's implemented, but it seems over-constrained. And the last phrase seems wrong. p is an X::value_type, X::reference(a[n] = v) is equivalent to p = v.
iterator; there's no requirement that you can assign a value_type object to it. Should that be *p = This needs to define 'a', but assuming it's supposed to be
v? But why the cast in reference(a[n] = v)? ``*this`` (or maybe ``*(Derived*)this``), it still isn't clear
what this says. Presumably, the idea is that you can index off of
an iterator and assign to the result. But why the requirement
that it hold a copy of a+n? Granted, that's probably how it's
implemented, but it seems over-constrained. And the last phrase
seems wrong. p is an iterator; there's no requirement that you
can assign a value_type object to it. Should that be ``*p = v``?
But why the cast in reference(a[n] = v)?
:Proposed resolution: **Needs work**
Proposed resolution: **** Needs work ****
Change *this to *static_cast<Derived*>(this). Also reword the stuff Change *this to *static_cast<Derived*>(this). Also reword the stuff
about X::reference(a[n] = v) is equivalent to p = v. about X::reference(a[n] = v) is equivalent to p = v.
9.27 Iterator_facade: redundant clause 9.27 Iterator_facade: redundant clause
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
operator- has both an effects clause and a returns clause. Looks like the returns clause should be operator- has both an effects clause and a returns clause. Looks like the returns clause should be
removed. removed.
Proposed resolution: :Proposed resolution: Remove the returns clause.
Remove the returns clause.
9.28 indirect_iterator: incorrect specification of default constructor 9.28 indirect_iterator: incorrect specification of default constructor
Submitter: Pete Becker :Submitter: Pete Becker
Status: New :Status: New
The default constructor returns "An instance of indirect_iterator with a default constructed base The default constructor returns "An instance of indirect_iterator with a default constructed base
object", but the constructor that takes an Iterator object returns "An instance of indirect_iterator object", but the constructor that takes an Iterator object returns "An instance of indirect_iterator
with the iterator_adaptor subobject copy constructed from x." The latter is the correct form, since with the iterator_adaptor subobject copy constructed from x." The latter is the correct form, since
it does not reach inside the base class for its semantics. So the default constructor shoudl return it does not reach inside the base class for its semantics. So the default constructor shoudl return
"An instance of indirect_iterator with a default-constructed iterator_adaptor subobject." "An instance of indirect_iterator with a default-constructed iterator_adaptor subobject."
Proposed resolution: :Proposed resolution: Change the effects clause to
Change the effects clause to
Effects: Constructs an instance of indirect_iterator with a default Effects: Constructs an instance of indirect_iterator with a default
constructed iterator_adaptor subobject. constructed iterator_adaptor subobject.
9.29 indirect_iterator: unclear specification of template constructor 9.29 indirect_iterator: unclear specification of template constructor
Submitter: Pete Becker =====================================================================
Status: New
:Submitter: Pete Becker
:Status: New
The templated constructor that takes an indirect_iterator with a different set of template The templated constructor that takes an indirect_iterator with a different set of template
arguments says that it returns "An instance of indirect_iterator that is a copy of [the argument]". arguments says that it returns "An instance of indirect_iterator that is a copy of [the argument]".
But the type of the argument is different from the type of the object being constructed, and there But the type of the argument is different from the type of the object being constructed, and there
@@ -529,31 +611,38 @@ Is that what's meant here?
constructor like this: the constructor returns "a copy" of the argument without saying what a constructor like this: the constructor returns "a copy" of the argument without saying what a
copy is.) copy is.)
Proposed resolution: :Proposed resolution: Change the effects clause to
Change the effects clause to
Effects: Constructs an instance of indirect_iterator whose Effects: Constructs an instance of indirect_iterator whose
iterator_adaptor subobject is constructed from y.base(). iterator_adaptor subobject is constructed from y.base().
9.30 transform_iterator argument irregularity 9.30 transform_iterator argument irregularity
Submitter: Pete Becker =============================================
Status: New
:Submitter: Pete Becker
:Status: New
The specialized adaptors that take both a Value and a Reference template argument all take them The specialized adaptors that take both a Value and a Reference template argument all take them
in that order, i.e. Value precedes Reference in the template argument list, with the exception of in that order, i.e. Value precedes Reference in the template argument list, with the exception of
transform_iterator, where Reference precedes Value. This seems like a possible source of transform_iterator, where Reference precedes Value. This seems like a possible source of
confusion. Is there a reason why this order is preferable? confusion. Is there a reason why this order is preferable?
Proposed resolution: :Proposed resolution: Change the argument order so that Value precedes reference.
Change the argument order so that Value precedes reference.
9.31 function_output_iterator overconstrained 9.31 function_output_iterator overconstrained
Submitter: Pete Becker =============================================
Status: New
:Submitter: Pete Becker
:Status: New
function_output_iterator requirements says: "The UnaryFunction must be Assignable, Copy function_output_iterator requirements says: "The UnaryFunction must be Assignable, Copy
Constructible, and the expression f(x) must be valid, where f is an object of type UnaryFunction Constructible, and the expression f(x) must be valid, where f is an object of type UnaryFunction
and x is an object of a type accepted by f." and x is an object of a type accepted by f."
Everything starting with "and," somewhat reworded, is actually a constraint on Everything starting with "and," somewhat reworded, is actually a constraint on
output_proxy::operator=. All that's needed to create a function_output_iterator object is that the output_proxy::operator=. All that's needed to create a function_output_iterator object is that the
UnaryFunction type be Assignable and CopyConstructible. That's also sufficient to dereference UnaryFunction type be Assignable and CopyConstructible. That's also sufficient to dereference
@@ -561,110 +650,137 @@ and to increment such an object. It's only when you try to assign through a dere
that f(x) has to work, and then only for the particular function object that the iterator holds and that f(x) has to work, and then only for the particular function object that the iterator holds and
for the particular value that is being assigned. for the particular value that is being assigned.
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy) Agree, need to find wording.
Agree, need to find wording.
9.32 Should output_proxy real 9.32 Should output_proxy really be a named type?
y be a named type? ================================================
Submitter: Pete Becker
Status: New :Submitter: Pete Becker
:Status: New
This means someone can store an output_proxy object for later use, whatever that means. It also This means someone can store an output_proxy object for later use, whatever that means. It also
constrains output_proxy to hold a copy of the function object, rather than a pointer to the iterator constrains output_proxy to hold a copy of the function object, rather than a pointer to the iterator
object. Is all this mechanism really necessary? object. Is all this mechanism really necessary?
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy) Agree, need to find wording.
Agree, need to find wording.
9.33 istreambuf_iterator isn't a Readable Iterator 9.33 istreambuf_iterator isn't a Readable Iterator
Submitter: Pete Becker ==================================================
Status: New
:Submitter: Pete Becker
:Status: New
c++std-lib-12333: c++std-lib-12333:
N1550 requires that for a Readable Iterator a of type X, *a returns an object of type N1550 requires that for a Readable Iterator a of type X, *a returns an object of type
iterator_traits<X>::reference. istreambuf_iterator::operator* returns charT, but iterator_traits<X>::reference. istreambuf_iterator::operator* returns charT, but
istreambuf_iterator::reference is charT&. So am I overlooking something, or is istreambuf_iterator::reference is charT&. So am I overlooking something, or is
istreambuf_iterator not Readable istreambuf_iterator not Readable
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)
Remove requirements on the reference type from Readable Iterator. Remove requirements on the reference type from Readable Iterator.
9.34 iterator_facade free functions unspecified 9.34 iterator_facade free functions unspecified
Submitter: Pete Becker ===============================================
Status: New
:Submitter: Pete Becker
:Status: New
c++std-lib-12562: c++std-lib-12562:
The template functions operator==, operator!=, operator<, operator<=, operator>, operator>=, The template functions operator==, operator!=, operator<, operator<=, operator>, operator>=,
and operator- that take two arguments that are specializations of iterator_facade have no and operator- that take two arguments that are specializations of iterator_facade have no
specification. The template function operator+ that takes an argument that is a specialization of specification. The template function operator+ that takes an argument that is a specialization of
iterator_facade and an argument of type difference_type has no specification. iterator_facade and an argument of type difference_type has no specification.
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work** Add the missing specifications.
Add the missing specifications.
9.35 iterator_facade: too many equals? 9.35 iterator_facade: too many equals?
Submitter: Pete Becker ======================================
Status: New
:Submitter: Pete Becker
:Status: New
c++std-lib-12563: c++std-lib-12563:
The table listing the functions required for types derived from iterator_facade has two functions The table listing the functions required for types derived from iterator_facade has two functions
named equal and two named distance_to: named equal and two named distance_to::
c.equal(b) c.equal(b)
c.equal(y) c.equal(y)
c.distance_to(b) c.distance_to(b)
c.distance_to(z) c.distance_to(z)
where b and c are const objects of the derived type, y and z are constant objects of certain iterator where b and c are const objects of the derived type, y and z are constant objects of certain iterator
types that are interoperable with the derived type. types that are interoperable with the derived type.
Seems like the 'b' versions are redundant: in both cases, the other version will take a 'b'. In fact, Seems like the 'b' versions are redundant: in both cases, the other version will take a 'b'. In fact,
iterator_adaptor is specified to use iterator_facade, but does not provide the 'b' versions of these iterator_adaptor is specified to use iterator_facade, but does not provide the 'b' versions of these
functions. functions.
Are the 'b' versions needed? Are the 'b' versions needed?
Proposed resolution: :Proposed resolution: Remove the 'b' versions.
Remove the 'b' versions.
9.36 iterator_facade function requirements 9.36 iterator_facade function requirements
Submitter: Pete Becker ==========================================
Status: New
:Submitter: Pete Becker
:Status: New
c++std-lib-12636: c++std-lib-12636:
The table that lists required functions for the derived type X passed to iterator_facade lists, The table that lists required functions for the derived type X passed to iterator_facade lists,
among others: among others:
for a single pass iterator: for a single pass iterator::
c.equal(b) c.equal(b)
c.equal(y) c.equal(y)
where b and c are const X objects, and y is a const object of a single pass iterator that is where b and c are const X objects, and y is a const object of a single pass iterator that is
interoperable with X. Since X is interoperable with itself, c.equal(b) is redundant. There is a interoperable with X. Since X is interoperable with itself, c.equal(b) is redundant. There is a
difference in their descriptions, but its meaning isn't clear. The first is "true iff b and c are difference in their descriptions, but its meaning isn't clear. The first is "true iff b and c are
equivalent", and the second is "true iff c and y refer to the same position." Is there a difference equivalent", and the second is "true iff c and y refer to the same position." Is there a difference
between the undefined term "equivalent" and "refer to the same position"? between the undefined term "equivalent" and "refer to the same position"?
Similarly, for a random access traversal iterator: Similarly, for a random access traversal iterator::
c.distance_to(b) c.distance_to(b)
c.distance_to(z) c.distance_to(z)
where z is a constant object of a random access traversal iterator that is interoperable with X. where z is a constant object of a random access traversal iterator that is interoperable with X.
Again, X is interoperable with itself, so c.distance_to(b) is redundant. Again, X is interoperable with itself, so c.distance_to(b) is redundant.
Also, the specification for c.distance_to(z) isn't valid. It's written as "equivalent to distance(c, Also, the specification for c.distance_to(z) isn't valid. It's written as "equivalent to distance(c,
z)". The template function distance takes two arguments of the same type, so distance(c, z) isn't z)". The template function distance takes two arguments of the same type, so distance(c, z) isn't
valid if c and z are different types. Should it be distance(c, (X)z)? valid if c and z are different types. Should it be distance(c, (X)z)?
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work**
We need to define what "same position" means for iterators. This also We need to define what "same position" means for iterators. This also
needs to be part of the definition of an Interoperable Iterator needs to be part of the definition of an Interoperable Iterator
concept. concept.
======================================================================================== ====================================
More Issues (not from Matt's list) More Issues (not from Matt's list)
======================================================================================== ====================================
Inheritance in iterator_adaptor and other adaptors is an overspecification Inheritance in iterator_adaptor and other adaptors is an overspecification
Submitter: Pete Becker ==========================================================================
Status: New
:Submitter: Pete Becker
:Status: New
c++std-lib-12696: c++std-lib-12696:
The paper requires that iterator_adaptor be derived from an The paper requires that iterator_adaptor be derived from an
appropriate instance of iterator_facade, and that most of the specific appropriate instance of iterator_facade, and that most of the specific
@@ -673,7 +789,8 @@ iterator_adaptor. That seems like overspecification, and we ought to
look at specifying these things in terms of what the various templates look at specifying these things in terms of what the various templates
provide rather than how they're implemented. provide rather than how they're implemented.
Proposed resolution: **** Needs work **** :Proposed resolution: **Needs work**
Remove the specfication of inheritance, and add lots of specification Remove the specfication of inheritance, and add lots of specification
to make for it. In iterator_adaptor, that means duplicating a lot of to make for it. In iterator_adaptor, that means duplicating a lot of
function prototypes. In the other adaptors, that means making sure we function prototypes. In the other adaptors, that means making sure we
@@ -685,48 +802,59 @@ specialized adaptors. -Jeremy
Problem with specification of a->m in Readable Iterator Problem with specification of a->m in Readable Iterator
Submitter: Howard Hinnant =======================================================
Status: New
:Submitter: Howard Hinnant
:Status: New
c++std-lib-12585: c++std-lib-12585:
Readable Iterator Requirements says Readable Iterator Requirements says::
a->m U& pre: (*a).m is well-defined. Equivalent to (*a).m a->m U& pre: (*a).m is well-defined. Equivalent to (*a).m
Do we mean to outlaw iterators with proxy references from meeting the Do we mean to outlaw iterators with proxy references from meeting the
readable requirements? readable requirements?
Would it be better for the requirements to read static_cast<T>(*a).m
instead of (*a).m ?
Proposed resolution: Would it be better for the requirements to read ``static_cast<T>(*a).m``
Change the requirement to instead of ``(*a).m`` ?
pre: static_cast<T const&>(*a).m is well-defined. If
static_cast<T&>(*a).m is well-defined, equivalent to
static_cast<T&>(*a).m; otherwise, equivalent to
static_cast<T const&>(*a).m.
:Proposed resolution: Change the requirement to
:pre: ``static_cast<T const&>(*a).m`` is well-defined. If
``static_cast<T&>(*a).m`` is well-defined, equivalent to
``static_cast<T&>(*a).m``; otherwise, equivalent to
``static_cast<T const&>(*a).m``.
counting_iterator Traversal argument unspecified counting_iterator Traversal argument unspecified
Submitter: Pete Becker ================================================
:Submitter: Pete Becker
c++std-lib-12635: c++std-lib-12635:
counting_iterator takes an argument for its Traversal type, with a default counting_iterator takes an argument for its Traversal type, with a
value of use_default. It is derived from an instance of iterator_adaptor, default value of use_default. It is derived from an instance of
where the argument passed for the Traversal type is described as "/* see iterator_adaptor, where the argument passed for the Traversal type
details for traversal category */". The details for counting_iterator is described as "\ ``/* see details for traversal category
describe constraints on the Incrementable type imposed by various traversal */``". The details for counting_iterator describe constraints on
the Incrementable type imposed by various traversal
categories. There is no description of what the argument to categories. There is no description of what the argument to
iterator_adaptor should be. iterator_adaptor should be.
Proposed resolution: **** Needs work **** (Jeremy) :Proposed resolution: **Needs work** (Jeremy)
indirect_iterator requirements muddled indirect_iterator requirements muddled
Submitter: Pete Becker ======================================
c++std-lib-12640
:Submitter: Pete Becker
c++std-lib-12640::
>The value_type of the Iterator template parameter should itself be >The value_type of the Iterator template parameter should itself be
>dereferenceable. The return type of the operator* for the value_type must >dereferenceable. The return type of the operator* for the value_type must
@@ -735,7 +863,7 @@ c++std-lib-12640
I'd say this a bit differently, to emphasize what's required: I'd say this a bit differently, to emphasize what's required:
iterator_traits<Iterator>::value_type must be dereferenceable. iterator_traits<Iterator>::value_type must be dereferenceable.
The Reference template parameter must be the same type as The Reference template parameter must be the same type as
*iterator_traits<Iterator>::value_type(). ``*iterator_traits<Iterator>::value_type()``.
>The Value template parameter will be the value_type for the >The Value template parameter will be the value_type for the
>indirect_iterator, unless Value is const. If Value is const X, then >indirect_iterator, unless Value is const. If Value is const X, then
@@ -757,13 +885,17 @@ pun, or is iterator_traits<Iterator>::value_type required to be some form
of iterator? If it's the former we need to find a different way to say it. of iterator? If it's the former we need to find a different way to say it.
If it's the latter we need to say so. If it's the latter we need to say so.
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)
Problem with transform_iterator requirements Problem with transform_iterator requirements
Submitter: Pete Becker ============================================
c++std-lib-12641:
:Submitter: Pete Becker
c++std-lib-12641::
>The reference type of transform_iterator is >The reference type of transform_iterator is
>result_of<UnaryFunction(iterator_traits<Iterator>::reference)>::type. The >result_of<UnaryFunction(iterator_traits<Iterator>::reference)>::type. The
>value_type is remove_cv<remove_reference<reference> >::type. >value_type is remove_cv<remove_reference<reference> >::type.
@@ -773,14 +905,14 @@ what gets passed to iterator_adaptor. And again, the specification should
be in terms of the specialization of iterator_adaptor, and not in terms of be in terms of the specialization of iterator_adaptor, and not in terms of
the result: the result:
Reference argument to iterator_adaptor: Reference argument to iterator_adaptor::
if (Reference != use_default) if (Reference != use_default)
Reference Reference
else else
result_of<UnaryFunction(iterator_traits<Iterator>::reference)>::type result_of<UnaryFunction(iterator_traits<Iterator>::reference)>::type
Value argument to iterator_adaptor: Value argument to iterator_adaptor::
if (Value != use_default) if (Value != use_default)
Value Value
@@ -793,16 +925,17 @@ There's probably a better way to specify that last alternative, but I've
been at this too long, and it's all turning into a maze of twisty passages, been at this too long, and it's all turning into a maze of twisty passages,
all alike. all alike.
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)
filter_iterator details unspecified filter_iterator details unspecified
Submitter: Pete Becker ===================================
:Submitter: Pete Becker
c++std-lib-12642: c++std-lib-12642:
The paper says: The paper says::
template<class Predicate, class Iterator> template<class Predicate, class Iterator>
class filter_iterator class filter_iterator
@@ -813,11 +946,11 @@ The paper says:
/* see details */ > /* see details */ >
That comment covers the Access, Traversal, Reference, and Difference That comment covers the Access, Traversal, Reference, and Difference
arguments. The only specification for any of these in the details is: arguments. The only specification for any of these in the details is::
>The access category of the filter_iterator will be the same as the access >The access category of the filter_iterator will be the same as
>category of Iterator. >the access category of Iterator.
Needs more. Needs more.
Proposed resolution: **** Needs work ****(Jeremy) :Proposed resolution: **Needs work** (Jeremy)