Title
copy_n's number of InputIterator increments unspecified
Status
open
Section
[alg.copy]
Submitter
Jonathan Wakely

Created on 2015-01-28.00:00:00 last changed 70 months ago

Messages

Date: 2018-06-22.06:38:21

[ LEWG Kona 2017 ]

This is a mess. Append to Effects: If the InputIterator is not a forward iterator, increments n-1 times. Otherwise the number of increments is not more than n. (ncm) The preceding proposition is unsatisfactory, because it is wrong for istreambuf_iterator, which is much more useful than istream_iterator. Proposing instead: Append to Effects: If InputIterator is istream_iterator for some T, increments n-1 times. Otherwise, increments n times. Want a paper exploring what the implementations actually do, and what non-uniformity is "right".

Status to Open

Date: 2016-08-03.12:32:27

[ 2016-08 Chicago ]

Tues PM: refer to LEWG

Date: 2015-01-28.00:00:00

It's unspecified how many times copy_n increments the InputIterator. uninitialized_copy_n is specified to increment it exactly n times, which means if an istream_iterator is used then the next character after those copied is read from the stream and then discarded, losing data.

I believe all three of Dinkumware, libc++ and libstdc++ implement copy_n with n - 1 increments of the InputIterator, which avoids reading and discarding a character when used with istream_iterator, but is inconsistent with uninitialized_copy_n and causes surprising behaviour with istreambuf_iterator instead, because copy_n(in, 2, copy_n(in, 2, out)) is not equivalent to copy_n(in, 4, out)

History
Date User Action Args
2018-06-22 06:38:21adminsetmessages: + msg9975
2018-06-22 06:38:21adminsetstatus: lewg -> open
2016-08-03 12:32:27adminsetmessages: + msg8357
2016-08-03 12:32:27adminsetstatus: new -> lewg
2015-01-28 00:00:00admincreate