This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 26.7.9[alg.unique]Status:CD1Submitter: Angelika LangerOpened: 2000-05-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.unique].
View all issues withCD1 status.
Discussion:
Some popular implementations of unique_copy() create temporarycopies of values in the input sequence, at least if the input iteratoris a pointer. Such an implementation is built on the assumption thatthe value type is CopyConstructible and Assignable.
It is common practice in the standard that algorithms explicitlyspecify any additional requirements that they impose on any of thetypes used by the algorithm. An example of an algorithm that createstemporary copies and correctly specifies the additional requirementsis accumulate(), 29.5.3[rand.req].
Since the specifications of unique() and unique_copy() do notrequire CopyConstructible and Assignable of the InputIterator's valuetype the above mentioned implementations are not standard-compliant. Icannot judge whether this is a defect in the standard or a defect inthe implementations.
Proposed resolution:
In 25.2.8 change:
-4- Requires: The ranges [first, last) and [result, result+(last-first))shall not overlap.
to:
-4- Requires: The ranges [first, last) and [result, result+(last-first)) shall not overlap. The expression *result = *first must be valid. If neither InputIterator nor OutputIterator meets the requirements of forward iterator then the value type of InputIterator must be copy constructible. Otherwise copy constructible is not required.
[Redmond: the original proposed resolution didn't impose anexplicit requirement that the iterator's value type must be copyconstructible, on the grounds that an input iterator's value type mustalways be copy constructible. Not everyone in the LWG thought thatthis requirement was clear from table 72. It has been suggested thatit might be possible to implementunique_copy withoutrequiring assignability, although current implementations do imposethat requirement. Howard provided new wording.]
[Curaçao: The LWG changed the PR editorially to specify"neither...nor...meet..." as clearer than"both...and...do not meet...". Change believed to be sominor as not to require re-review.]