7

According to most C++ references, for instance cplusplus.com, forward iterators are not required to be assignable (I mean, deferenced to an lvalue). However, for several STL algorithms that need to write values, for instance std::fill (also std::generate etc.), the specification uses forward iterator:

template <class ForwardIterator, class T>
  void fill (ForwardIterator first, ForwardIterator last, const T& val);

while the equivalent behavior requires lvalue dereference:

template <class ForwardIterator, class T>
  void fill (ForwardIterator first, ForwardIterator last, const T& val)
{
  while (first != last) {
    *first = val;
    ++first;
  }
}

So, it is actually using a mutable forward iterator with a single pass.

Now the questions are:

(1) Why not make it clear that the forward iterators used in these cases are mutable?

(2) Update: I found the following question to be stupid: I temporarily forgot that output iterators do not need to support equality comparison. The above question remains, anyway.

Why use forward iterators instead of output iterators for std::fill, std::generate etc. while they do not actually need multiple passes? (std::copy only needs output iterators, for instance. What's the rationale?)

4ae1e1
  • 7,228
  • 8
  • 44
  • 77
  • `forward iterators are not required to be assignable`, how did you determine that? I'm pretty sure they are assignable. – Jesse Good Apr 29 '13 at 23:57
  • @JesseGood For practical purposes they are almost always assignable, but if you read the reference http://cplusplus.com/reference/iterator/ForwardIterator/?kw=forward%20iterator it isn't. – 4ae1e1 Apr 30 '13 at 00:01
  • 1
    @JesseGood I also found this on SO: http://stackoverflow.com/questions/14058642/are-forward-iterators-output-iterators – 4ae1e1 Apr 30 '13 at 00:03
  • Thanks for the link, I was unaware of that. That link also is linked to [this SO question](http://stackoverflow.com/questions/14062297/canonical-way-to-define-forward-output-iterator) which I think answers your question. – Jesse Good Apr 30 '13 at 00:13
  • @JesseGood Thanks, an interesting read. After reading the thread you referred to, the problem seems more like a defect in the standard to me. – 4ae1e1 Apr 30 '13 at 00:26

2 Answers2

5

From the signature

template <class ForwardIterator, class T>
void fill (ForwardIterator first, ForwardIterator last, const T& val);

you cannot infer that ForwardIterator is an iterator described in forward iterator. However, if you read the parameter description, you will find that first and last must be

Forward Iterators to the initial and final positions in a sequence of elements that support being assigned a value of type T.

(emphasis by me). So a forward iterator that fulfills nothing more than what is required of a forward iterator is not a valid argument.

Oswald
  • 31,254
  • 3
  • 43
  • 68
  • Yeah, that's a good point. But the signature is tricky from a standard point of view. – 4ae1e1 Apr 30 '13 at 00:27
  • The alternative would be to introduce a new name for forward iterators that support assignemt to the pointed to element. – Oswald Apr 30 '13 at 00:33
1

It doesn't seem terribly strange to me, given that the specification for fill is that the (dereferenced) iterator be assignable from T. An output iterator won't suffice because it's not comparable to determine the range end, so a forward_iterator with requirements was chosen.

You'll note that fill_n does use output iterators because no iterator comparison is needed to determine the end of the sequence to fill.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • I think OP’s point is that the forward iterator concept is *required* but not *sufficient* to specify the requirements for the argument type. The same would go for “output iterator”; only by requiring that the argument be *both* do we get the correct semantics. Put differently, there are forward iterators on which `std::fill` cannot be called. – Konrad Rudolph Apr 30 '13 at 01:21