From 3fd1c34411694a2a23c2ddaa94c0770a0d2de0a1 Mon Sep 17 00:00:00 2001 From: Michel Morin Date: Wed, 13 Nov 2013 03:22:55 +0000 Subject: [PATCH] Merge r86524 (Correct broken links to C++ standard papers); fixes #9212 [SVN r86673] --- doc/facade-and-adaptor.html | 18 +++++++++--------- doc/facade-and-adaptor.rst | 8 ++++---- doc/issues.rst | 2 +- doc/iterator_facade.html | 4 ++-- doc/iterator_facade_body.rst | 4 ++-- doc/new-iter-concepts.html | 16 ++++++++-------- doc/new-iter-concepts.rst | 16 ++++++++-------- doc/quickbook/facade.qbk | 4 ++-- doc/ref_problem.rst | 2 +- 9 files changed, 37 insertions(+), 37 deletions(-) mode change 100755 => 100644 doc/facade-and-adaptor.html mode change 100755 => 100644 doc/issues.rst mode change 100755 => 100644 doc/new-iter-concepts.html diff --git a/doc/facade-and-adaptor.html b/doc/facade-and-adaptor.html old mode 100755 new mode 100644 index 630ddcb..79d38a3 --- a/doc/facade-and-adaptor.html +++ b/doc/facade-and-adaptor.html @@ -26,7 +26,7 @@ Lab, Zephyr Associates, Inc. Date: 2006-09-11 -Number:This is a revised version of N1530=03-0113, which was +Number:This is a revised version of N1530=03-0113, which was accepted for Technical Report 1 by the C++ standard committee's library working group. @@ -239,29 +239,29 @@ Iterator Concepts.

Iterator Concepts

This proposal is formulated in terms of the new iterator concepts -as proposed in n1550, since user-defined and especially adapted +as proposed in n1550, since user-defined and especially adapted iterators suffer from the well known categorization problems that are inherent to the current iterator categories.

-

This proposal does not strictly depend on proposal n1550, as there +

This proposal does not strictly depend on proposal n1550, as there is a direct mapping between new and old categories. This proposal -could be reformulated using this mapping if n1550 was not accepted.

+could be reformulated using this mapping if n1550 was not accepted.

Interoperability

The question of iterator interoperability is poorly addressed in the current standard. There are currently two defect reports that are concerned with interoperability issues.

-

Issue 179 concerns the fact that mutable container iterator types +

Issue 179 concerns the fact that mutable container iterator types are only required to be convertible to the corresponding constant iterator types, but objects of these types are not required to interoperate in comparison or subtraction expressions. This situation is tedious in practice and out of line with the way built in types work. This proposal implements the proposed resolution to issue -179, as most standard library implementations do nowadays. In other +179, as most standard library implementations do nowadays. In other words, if an iterator type A has an implicit or user defined conversion to an iterator type B, the iterator types are interoperable and the usual set of operators are available.

-

Issue 280 concerns the current lack of interoperability between +

Issue 280 concerns the current lack of interoperability between reverse iterator types. The proposed new reverse_iterator template fixes the issues raised in 280. It provides the desired interoperability without introducing unwanted overloads.

@@ -422,8 +422,8 @@ member (e.g. p+n, which is destroyed when operator[] returns.

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 +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 diff --git a/doc/facade-and-adaptor.rst b/doc/facade-and-adaptor.rst index 1be63e8..6308de4 100644 --- a/doc/facade-and-adaptor.rst +++ b/doc/facade-and-adaptor.rst @@ -19,7 +19,7 @@ .. Version 1.9 of this ReStructuredText document corresponds to n1530_, the paper accepted by the LWG. -.. _n1530: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1530.html +.. _n1530: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1530.html :copyright: Copyright David Abrahams, Jeremy Siek, and Thomas Witt 2003. @@ -140,7 +140,7 @@ as proposed in n1550_, since user-defined and especially adapted iterators suffer from the well known categorization problems that are inherent to the current iterator categories. -.. _n1550: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1550.html +.. _n1550: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1550.htm This proposal does not strictly depend on proposal n1550_, as there is a direct mapping between new and old categories. This proposal @@ -169,8 +169,8 @@ reverse iterator types. The proposed new reverse_iterator template fixes the issues raised in 280. It provides the desired interoperability without introducing unwanted overloads. -.. _179: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#179 -.. _280: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#280 +.. _179: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179 +.. _280: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#280 Iterator Facade diff --git a/doc/issues.rst b/doc/issues.rst old mode 100755 new mode 100644 index 5ddb61f..a36f5a9 --- a/doc/issues.rst +++ b/doc/issues.rst @@ -3,7 +3,7 @@ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. _N1550: http://www.boost-consulting.com/writing/n1550.html -.. _N1530: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1530.html +.. _N1530: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1530.html :Author: David Abrahams and Jeremy Siek :Contact: dave@boost-consulting.com, jsiek@osl.iu.edu diff --git a/doc/iterator_facade.html b/doc/iterator_facade.html index 57a69c0..21e048d 100644 --- a/doc/iterator_facade.html +++ b/doc/iterator_facade.html @@ -242,8 +242,8 @@ member (e.g. p+n, which is destroyed when operator[] returns.

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 +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 diff --git a/doc/iterator_facade_body.rst b/doc/iterator_facade_body.rst index 4b3059d..d0a13fe 100644 --- a/doc/iterator_facade_body.rst +++ b/doc/iterator_facade_body.rst @@ -167,9 +167,9 @@ the implementation of her iterator is free to implement an class; it will hide the one supplied by ``iterator_facade`` from clients of her iterator. -.. _n1550: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1550.html +.. _n1550: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1550.htm -.. _`issue 299`: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299 +.. _`issue 299`: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299 .. _`operator arrow`: diff --git a/doc/new-iter-concepts.html b/doc/new-iter-concepts.html old mode 100755 new mode 100644 index 51a4ee0..426bede --- a/doc/new-iter-concepts.html +++ b/doc/new-iter-concepts.html @@ -27,10 +27,10 @@ Lab, Zephyr Associates, Inc. Date: 2006-09-11 -Number:This is a revised version of n1550=03-0133, which was +Number:This is a revised version of n1550=03-0133, which was accepted for Technical Report 1 by the C++ standard committee's library working group. This proposal is a -revision of paper n1297, n1477, and n1531. +revision of paper n1297, n1477, and n1531. Copyright: Copyright David Abrahams, Jeremy Siek, and Thomas Witt @@ -127,12 +127,12 @@ requirements in the iterator categories.

*i is convertible to T Forward Iterator -*i is T& (or const T& once issue 200 +*i is T& (or const T& once issue 200 is resolved) Random Access Iterator i[n] is convertible to T (also i[n] = t -is required for mutable iterators once issue 299 +is required for mutable iterators once issue 299 is resolved) @@ -141,7 +141,7 @@ is resolved) single hierarchy, many useful iterators can not be appropriately categorized. For example, vector<bool>::iterator is almost a random access iterator, but the return type is not bool& (see -issue 96 and Herb Sutter's paper J16/99-0008 = WG21 +issue 96 and Herb Sutter's paper J16/99-0008 = WG21 N1185). Therefore, the iterators of vector<bool> only meet the requirements of input iterator and output iterator. This is so nonintuitive that the C++ standard contradicts itself on this point. @@ -344,7 +344,7 @@ approach for specifying operator[ direction would mean that an iterator satisfying the old Random Access Iterator requirements would not necessarily be a model of Readable or Writable Lvalue Iterator. Instead we have chosen a design that -matches the preferred resolution of issue 299: operator[] is +matches the preferred resolution of issue 299: operator[] is only required to return something convertible to the value_type (for a Readable Iterator), and is required to support assignment i[n] = t (for a Writable Iterator).

@@ -976,7 +976,7 @@ struct random_access_traversal_tag : bidirectional_traversal_tag { };

Addition to [lib.iterator.traits]

The is_readable_iterator class -template satisfies the UnaryTypeTrait requirements.

+template satisfies the UnaryTypeTrait requirements.

Given an iterator type X, is_readable_iterator<X>::value yields true if, for an object a of type X, *a is convertible to iterator_traits<X>::value_type, and false @@ -1007,7 +1007,7 @@ otherwise.

Footnotes

-

The UnaryTypeTrait concept is defined in n1519; the LWG is +

The UnaryTypeTrait concept is defined in n1519; the LWG is considering adding the requirement that specializations are derived from their nested ::type.