iter-issue-list.rst

boost库提供标准的C++ API 配合dev c++使用,功能更加强大

    +-------------------------------------------+-------------------------------------------------+-------------------------+----------------------+
    |``traversal_category<X>::type``            |Convertible to                                   |                         |                      |
    |                                           |``random_access_traversal_iterator_tag``         |                         |                      |
    +-------------------------------------------+-------------------------------------------------+-------------------------+----------------------+

  to:

    +-------------------------------+---------------------------------+-------------------------+----------------------+
    |``iterator_traversal<X>::type``|Convertible to                   |                         |                      |
    |                               |``random_access_traversal_tag``  |                         |                      |
    +-------------------------------+---------------------------------+-------------------------+----------------------+


  In [lib.iterator.synopsis], change::  

    struct incrementable_iterator_tag { };
    struct single_pass_iterator_tag : incrementable_iterator_tag { };
    struct forward_traversal_tag : single_pass_iterator_tag { };

  to::

    struct incrementable_traversal_tag { };
    struct single_pass_traversal_tag : incrementable_traversal_tag { };
    struct forward_traversal_tag : single_pass_traversal_tag { };

  Remove::

    struct null_category_tag { };
    struct input_output_iterator_tag : input_iterator_tag, output_iterator_tag {};


9.21 iterator_facade Derived template argument underspecified 
=============================================================

:Submitter: Pete Becker 
:Status: New 

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. 

First, iterator_facade is a template, so cannot be derived
from. Rather, the class must be derived from a specialization of
iterator_facade. More important, isn't Derived required to be the
class that is being defined? That is, if I understand it right, the
definition of D here this is not valid::

  class C : public iterator_facade<C, ... > { ... }; 
  class D : public iterator_facade<C, ...> { ... }; 

In the definition of D, the Derived argument to iterator_facade is
a class derived from a specialization of iterator_facade, so the
requirement is met. Shouldn't the requirement be more like "when
using iterator_facade to define an iterator class Iter, the class
Iter must be derived 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.

:Proposed resolution: 

  In [lib.iterator.facade]

  Remove:

    The ``Derived`` template parameter must be a class derived from
    ``iterator_facade``.
    
  Change:

    The following table describes the other requirements on the
    ``Derived`` parameter.  Depending on the resulting iterator's
    ``iterator_category``, a subset of the expressions listed in the table
    are required to be valid.  The operations in the first column must be
    accessible to member functions of class ``iterator_core_access``.
    
  to:

    The following table describes the typical valid expressions on
    ``iterator_facade``\ 's ``Derived`` parameter, depending on the
    iterator concept(s) it will model.  The operations in the first
    column must be made accessible to member functions of class
    ``iterator_core_access``.  In addition,
    ``static_cast<Derived*>(iterator_facade*)`` shall be well-formed.
    
  In [lib.iterator.adaptor]

  Change:

    The ``iterator_adaptor`` is a base class template derived from
    an instantiation of ``iterator_facade``.

  to:

    Each specialization of the ``iterator_adaptor`` class template
    is derived from a specialization of ``iterator_facade``.  

  Change:

    The ``Derived`` template parameter must be a derived class of
    ``iterator_adaptor``.

  To:

    ``static_cast<Derived*>(iterator_adaptor*)`` shall be well-formed.

[Note: The proposed resolution to Issue 9.37 contains related
changes]

9.22 return type of Iterator difference for iterator facade
===========================================================

:Submitter: Pete Becker 
:Status: New 

The proposal says::

  template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, 
  class Dr2, class V2, class AC2, class TC2, class R2, class D2>
  typename enable_if_interoperable<Dr1, Dr2, bool>::type
  operator -(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, 
  iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); 

Shouldn't the return type be one of the two iterator types? Which
one? The idea is that if one of 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?

:Proposed resolution:

   See resolution to 9.34.

9.23 Iterator_facade: minor wording Issue
=========================================

:Submitter: Pete Becker 
:Status: New 

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:

  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 used to implement
  them. Same thing in the description of c.distance_to(z).

:Proposed resolution: remove "implements" descriptions from
   table.  See resolution to 9.34


9.24 Use of undefined name in iterator_facade table 
===================================================

:Submitter: Pete Becker 
:Status: New 

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

:Proposed resolution: 

  Remove references to X.

  In [lib.iterator.facade] operations ``operator->() const;``:

    Change:

      :Returns: If ``X::reference`` is a reference type, an object
        of type ``X::pointer`` equal to::

          &static_cast<Derived const*>(this)->dereference()

	Otherwise returns an object of unspecified type such that,
	given an object ``a`` of type ``X``, ``a->m`` is equivalent
	to ``(w = *a, w.m)`` for some temporary object ``w`` of type
	``X::value_type``.

        The type ``X::pointer`` is ``Value*`` if
        ``is_writable_iterator<X>::value`` is ``true``, and
        ``Value const*`` otherwise.

    to:

      :Returns: If ``reference`` is a reference type, an object
        of type ``pointer`` equal to::

          &static_cast<Derived const*>(this)->dereference()

        Otherwise returns an object of unspecified type such that,
        ``(*static_cast<Derived const*>(this))->m`` is equivalent
        to ``(w = **static_cast<Derived const*>(this), w.m)`` for
        some temporary object ``w`` of type ``value_type``.

    Further changes are covered by issue 9.26.

9.25 Iterator_facade: wrong return type 
=======================================

:Submitter: Pete Becker 
:Status: New 

Several of the member functions return a Derived object or a
Derived&. Their Effects clauses end with::

  return *this;

This should be ::

  return *static_cast<Derived*>(this);

:Proposed resolution: 

  In [lib.iterator.facade], in the effects clause
  of the following operations::

    Derived& operator++()
    Derived& operator--()
    Derived& operator+=(difference_type n)
    Derived& operator-=(difference_type n)

  Change:
    ``return *this``

  to:
    ``return *static_cast<Derived*>(this);``

9.26 Iterator_facade: unclear returns clause for operator[] 
===========================================================

:Submitter: Pete Becker 
: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 constant object v of type
  X::value_type, X::reference(a[n] = v) is equivalent to p = v.
  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 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: 

  In section operator[]:
 
    Change:
  
      Writable iterators built with ``iterator_facade`` implement
      the semantics required by the preferred resolution to `issue
      299` and adopted by proposal `n1477`: the result of ``p[n]``
      is a proxy object containing a copy of ``p+n``, and ``p[n] =
      x`` is equivalent to ``*(p + n) = x``.  This approach will
      work properly for any random-access iterator regardless of
      the other details of its implementation.  A user who knows
      more about the implementation of her iterator is free to
      implement an ``operator[]`` which returns an lvalue in the
      derived iterator class; it will hide the one supplied by
      ``iterator_facade`` from clients of her iterator.
  
    to:
  
      Writable iterators built with ``iterator_facade`` implement
      the semantics required by the preferred resolution to `issue
      299` and adopted by proposal `n1550`: the result of ``p[n]``
      is an object convertible to the iterator's ``value_type``,
      and ``p[n] = x`` is equivalent to ``*(p + n) = x`` (Note:
      This result object may be implemented as a proxy containing a
      copy of ``p+n``).  This approach will work properly for any
      random-access iterator regardless of the other details of its
      implementation.  A user who knows more about the
      implementation of her iterator is free to implement an
      ``operator[]`` that returns an lvalue in the derived iterator
      class; it will hide the one supplied by ``iterator_facade``
      from clients of her iterator.
  
  In [lib.iterator.facade] operations:

    Change:
  
     :Returns: an object convertible to ``X::reference`` and
        holding a copy *p* of ``a+n`` such that, for a constant
        object ``v`` of type ``X::value_type``, ``X::reference(a[n]
        = v)`` is equivalent to ``p = v``.
  
    to:
  
     :Returns: an object convertible to ``value_type``. For
        constant objects ``v`` of type ``value_type``, and ``n`` of
        type ``difference_type``, ``(*this)[n] = v`` is equivalent
        to ``*(*this + n) = v``, and ``static_cast<value_type
        const&>((*this)[n])`` is equivalent to
        ``static_cast<value_type const&>(*(*this + n))``
     

9.27 Iterator_facade: redundant clause 
======================================

:Submitter: Pete Becker 
:Status: New 

``operator-`` has both an effects clause and a returns
clause. Looks like the returns clause should be removed.

:Proposed resolution:

  Remove the returns clause.

  In [lib.iterator.facade] operations:
        
  Remove:
    :Returns: ``static_cast<Derived const*>(this)->advance(-n);`` 




9.28 indirect_iterator: incorrect specification of default constructor 
======================================================================

:Submitter: Pete Becker 
:Status: New 

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
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
"An instance of indirect_iterator with a default-constructed
iterator_adaptor subobject."

:Proposed resolution: 
  Change:
     :Returns: An instance of ``indirect_iterator``