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

updates

Browse Source 
[SVN r21735]
This commit is contained in:
Dave Abrahams
2004-01-14 18:04:41 +00:00
parent 36329b053d
commit 731576fbfe
1 changed files with 71 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -62,8 +62,8 @@ to be members or non-members.
or non-members. or non-members.
9.3 enable_if_interoperable needs standardese 9.3 enable_if_interoperable needs standardese (Dave)
============================================= ====================================================
:Submitter: Pete Becker :Submitter: Pete Becker
:Status: New :Status: New
@ -195,7 +195,7 @@ which doesn't require iterators to be copy constructible or assignable).
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: **Needs work** (Dave) Change it to normative :Proposed resolution: Changed it to normative
text. See the resolution of 9.4 text. See the resolution of 9.4
9.9 Reverse_iterator text is too informal 9.9 Reverse_iterator text is too informal
@ -258,7 +258,7 @@ transform_iterator has a private member named 'm_f' which should be marked "expo
:Proposed resolution: Mark the member m_f as exposition :Proposed resolution: Mark the member m_f as exposition
only. Note/DWA: I think this is NAD because the user can't only. Note/DWA: I think this is NAD because the user can't
detect it, though I'm happy to makr it exposition only. detect it, though I'm happy to mark it exposition only.
9.13 Unclear description of counting iterator 9.13 Unclear description of counting iterator
@ -534,8 +534,8 @@ awkward, but at the moment I don't see a better way of phrasing it.
need to be able to unambigously cast the iterator_facade specialisation need to be able to unambigously cast the iterator_facade specialisation
to Iter. to Iter.
9.22 return type of Iterator difference for iterator facade 9.22 return type of Iterator difference for iterator facade (Dave)
=========================================================== ==================================================================
:Submitter: Pete Becker :Submitter: Pete Becker
:Status: New :Status: New
@ -583,7 +583,8 @@ iterator_facade, the entry for c.equal(y) says:
not implement either of these operations. It is used to implement not implement either of these operations. It is used to implement
them. Same thing in the description of c.distance_to(z). them. Same thing in the description of c.distance_to(z).
:Proposed resolution: **Needs work** (Dave) Reword. :Proposed resolution: remove "implements" descriptions from
table. See resolution to 9.34
9.24 Use of undefined name in iterator_facade table 9.24 Use of undefined name in iterator_facade table
@ -598,7 +599,7 @@ below, X is the derived iterator type." Looks like the X:: qualifiers aren't rea
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 language** (Dave) Remove the use of X. :Proposed resolution: Removed the use of X.
9.25 Iterator_facade: wrong return type 9.25 Iterator_facade: wrong return type
@ -646,14 +647,7 @@ says:
can assign a value_type object to it. Should that be ``*p = v``? can assign a value_type object to it. Should that be ``*p = v``?
But why the cast in reference(a[n] = v)? But why the cast in reference(a[n] = v)?
:Proposed resolution: **Needs work** :Proposed resolution: Reworded.
(Dave)
Change ``*this`` to ``*static_cast<Derived*>(this)``. Also reword
the stuff about ``X::reference(a[n] = v)`` is equivalent to ``p =
v``. Also make sure whatever's written accounts for ``v = a[n]``
9.27 Iterator_facade: redundant clause 9.27 Iterator_facade: redundant clause
====================================== ======================================
@ -746,7 +740,12 @@ in that order, i.e. Value precedes Reference in the template argument list, with
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: Change the argument order so that Value precedes reference. :Proposed resolution: NAD
:Rationale: defaults for Value depend on Reference. A sensible
Value can almost always be computed from Reference. The first
parameter is UnaryFunction, so the argument order is already
different from the other adapters.
9.31 function_output_iterator overconstrained 9.31 function_output_iterator overconstrained
@ -766,9 +765,9 @@ 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: :Proposed resolution: Remove the part of the sentence
Remove the part of the sentence after "and". Remove the use of after "and". Remove the use of ``output_proxy`` and instead
``output_proxy`` and instead specify ``operator*`` in the following way. specify ``operator*`` in the following way.
``/* implementation defined */ operator*();`` ``/* implementation defined */ operator*();``
@ -788,8 +787,7 @@ This means someone can store an output_proxy object for later use, whatever that
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: :Proposed resolution: See issue 9.31.
See issue 9.31.
@ -820,8 +818,8 @@ c++std-lib-12333:
this issue for Readable Iterator and Lvalue Iterator. this issue for Readable Iterator and Lvalue Iterator.
9.34 iterator_facade free functions unspecified 9.34 iterator_facade free functions unspecified (Dave)
=============================================== ======================================================
:Submitter: Pete Becker :Submitter: Pete Becker
:Status: New :Status: New
@ -836,7 +834,7 @@ c++std-lib-12562:
iterator_facade and an argument of type difference_type has no iterator_facade and an argument of type difference_type has no
specification. specification.
:Proposed resolution: **Needs work** (Dave) Add the missing specifications. :Proposed resolution: **Needs work** Add the missing specifications.
9.35 iterator_facade: too many equals? 9.35 iterator_facade: too many equals?
@ -876,6 +874,7 @@ 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)
@ -898,12 +897,7 @@ c++std-lib-12636:
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** (Dave) :Proposed resolution: Removed the 'b' versions, added the cast.
We need to define what "same position" means for iterators. This also
needs to be part of the definition of an Interoperable Iterator
concept.
==================================== ====================================
More Issues (not from Matt's list) More Issues (not from Matt's list)
@ -925,19 +919,16 @@ 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** (Dave) :Proposed resolution:
Remove the specfication of inheritance, and explicit specification of Remove the specfication of inheritance, and explicit specification of
all the functionality that was inherited. In iterator_adaptor, that all the functionality that was inherited from the specialized
means adding a lot of function prototypes. In the other adaptors, that iterators.
means making sure we state what concepts are modeled, in addition to
specifying the semantics of some core operations. Also, the
Interoperable Iterators concept is added to the new iterator concepts,
and this concept is used in the specification of the iterator
adaptors.
.. The specialized adaptors have been updated. iterator facade and In iterator_adaptor, inheritance is retained, sorry NAD. Also,
adaptor still need to be updated. -JGS the Interoperable Iterators concept is added to the new iterator
concepts, and this concept is used in the specification of the
iterator adaptors.
Problem with specification of a->m in Readable Iterator Problem with specification of a->m in Readable Iterator
@ -958,12 +949,11 @@ readable requirements?
Would it be better for the requirements to read ``static_cast<T>(*a).m`` Would it be better for the requirements to read ``static_cast<T>(*a).m``
instead of ``(*a).m`` ? instead of ``(*a).m`` ?
:Proposed resolution: Change the requirement to :Proposed resolution: NAD.
:pre: ``static_cast<T const&>(*a).m`` is well-defined. If :Rationale: We think you're misreading "pre:".
``static_cast<T&>(*a).m`` is well-defined, equivalent to Also requiring proxy iterators to support ``->`` would make old
``static_cast<T&>(*a).m``; otherwise, equivalent to iterators not conform to new iterator requirements.
``static_cast<T const&>(*a).m``.
counting_iterator Traversal argument unspecified counting_iterator Traversal argument unspecified
@ -1031,14 +1021,7 @@ c++std-lib-12640:
to find a different way to say it. If it's the latter we need to to find a different way to say it. If it's the latter we need to
say so. say so.
:Proposed resolution: **Needs work** (Jeremy) :Proposed resolution: Resolved **Needs Language**
:Rationale:
iterator_facade just does remove_const<Value>::type, so value_type is
volatile if Value is.
Problem with transform_iterator requirements Problem with transform_iterator requirements
@ -1078,7 +1061,6 @@ been at this too long, and it's all turning into a maze of twisty passages,
all alike. all alike.
:Proposed resolution: :Proposed resolution:
Replace: Replace:
The reference type of transform_iterator is The reference type of transform_iterator is
@ -1123,7 +1105,6 @@ arguments. The only specification for any of these in the details is:
Needs more. Needs more.
:Proposed resolution: :Proposed resolution:
Add to the synopsis:: Add to the synopsis::
typedef iterator_traits<Iterator>::value_type value_type; typedef iterator_traits<Iterator>::value_type value_type;