Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++14 status.

2263. Comparing iterators and allocator pointers with different const-character

Section: 16.4.4.6[allocator.requirements], 23.2[container.requirements]Status:C++14Submitter: Howard HinnantOpened: 2013-06-25Last modified: 2016-01-28

Priority:1

View otheractive issues in [allocator.requirements].

View all otherissues in [allocator.requirements].

View all issues withC++14 status.

Discussion:

This ancient issue179⁽ⁱ⁾ says one ought to be able to compare iterators withconst_iterators from any given container. I'm having trouble finding words that guarantee this in C++11. This impacts not only a container's iterators, but also the allocator requirements in [llocator.requirements] surroundingpointer,const_pointer,void_pointer andconst_void_pointer. E.g. can one compare apointer with aconst_pointer?

Sinceallocator::pointer andconst_pointer are required to be random access iterators, one could expect that the179⁽ⁱ⁾ guarantees apply for them as well.

[Daniel comments:]

The wording for179⁽ⁱ⁾ was part of several working drafts (e.g. also inN3092) over some time and suddenly got lostinN3242, presumably by accident. Whatever wedecide for allocator pointers, I expect that we need to restore the179⁽ⁱ⁾ wording as part of the overall resolution:

Reinsert after 23.2[container.requirements] p6:

-6-begin() returns an iterator referring to the first element in the container.end() returns an iterator whichis the past-the-end value for the container. If the container is empty, thenbegin() == end();

-?- In the expressions

i == ji != ji < ji <= ji >= ji > ji - j

wherei andj denote objects of a container'siterator type, either or both may be replaced by an object of the container'sconst_iterator type referring to the same element with no change in semantics.

[2014-02-13 Issaquah, Daniel comments and suggests wording]

First, I didn't originally move the seemingly lost wording to the resolution section because I wanted to ensure that the committee double-checks the reason of this loss.

Second, albeit restoring this wording will restore the comparability ofconst_iterator anditerator ofcontainers specified in Clause 23, but this alone wouldnot imply that this guarantee automatically extends toall other iterators, simply because there is no fundamental relation between a mutable iterator and a constantiterator by itself. This relation only exists under specific conditions, for example for containers which provide two suchtypedefs of that kind. Thus the wording restoration wouldnot ensure that allocatorpointer andconst_pointer would be comparable with each other. To realize that, we would need additional guarantees addedto the allocator requirements. In fact, it is crucial to separate these things, because allocators arenot restricted to be used within containers, they have their own legitimate use for other places as well (albeit containerspresumably belong to the most important use-cases), and this is also stated in the introduction of 16.4.4.6[allocator.requirements],where it says:

All of the string types (Clause 21), containers (Clause 23) (except array), string buffers and string streams (Clause 27), andmatch_results (Clause 28) are parameterized in terms of allocators.

[2014-02-12 Issaquah meeting]

Move a Immediate.

Proposed resolution:

1. Insert after 16.4.4.6[allocator.requirements] p4 as indicated:

   -4- An allocator typeX shall satisfy the requirements ofCopyConstructible (17.6.3.1). TheX::pointer,X::const_pointer,X::void_pointer, andX::const_void_pointer types shall satisfy the requirementsofNullablePointer (17.6.3.3). No constructor, comparison operator, copy operation, move operation, orswap operation on these types shall exit via an exception.X::pointer andX::const_pointer shall alsosatisfy the requirements for a random access iterator (24.2).

   -?- Letx1 andx2 denote objects of (possibly different) typesX::void_pointer,X::const_void_pointer,X::pointer, orX::const_pointer. Then,x1 andx2areequivalently-valued pointer values, if and only if bothx1 andx2 can be explicitly converted to the two corresponding objectspx1 andpx2 of typeX::const_pointer, using a sequence ofstatic_casts using only these four types, and the expressionpx1 == px2 evaluates totrue.

   Drafting note: This wording uses the seemingly complicated route viaX::const_pointer, because these are (contrary toX::const_void_pointer) random access iterators and we can rely here for dereferenceable values on the fundamental pointeeequivalence of 24.3.5.5[forward.iterators] p6:

   Ifa andb are both dereferenceable, thena == b if and only if*a and*b are bound to the same object.

   while for null pointer values we can rely on the special equality relation induced by 16.4.4.4[nullablepointer.requirements].

   -?- Letw1 andw2 denote objects of typeX::void_pointer. Then for the expressions

   w1 == w2w1 != w2

   either or both objects may be replaced by an equivalently-valued object of typeX::const_void_pointer with no change in semantics.

   -?- Letp1 andp2 denote objects of typeX::pointer. Then for the expressions

   p1 == p2p1 != p2p1 < p2p1 <= p2p1 >= p2p1 > p2p1 - p2

   either or both objects may be replaced by an equivalently-valued object of typeX::const_pointer with no change in semantics.

2. Reinsert after 23.2[container.requirements] p6:

   -6-begin() returns an iterator referring to the first element in the container.end() returns an iterator whichis the past-the-end value for the container. If the container is empty, thenbegin() == end();

   -?- In the expressions

   i == ji != ji < ji <= ji >= ji > ji - j

   wherei andj denote objects of a container'siterator type, either or both may be replaced by an object of the container'sconst_iterator type referring to the same element with no change in semantics.