From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-06-07 03:13:44
John E. Potter wrote:
> There is no void& and you can't do anything with a void*. You can't
> read an output_iterator; so, it doesn't have a value_type => void.
I don't think that's that simple. First of all, the standard explicitly says
that notion of value type is valid for _all_ iterators:
24.1 [lib.iterator.requirements] para 1:
All iterators i support the expression *i, resulting in a value of some
class, enumeration, or built-in type T, called the value type of the
Second, the following two quotes imply that value type of an output iterator
is _not_ void, otherwise the cited requirements table's line is meaningless:
24.1 [lib.iterator.requirements] para 9: In the following sections, a and b
denote values of X, n denotes a value of the difference type Distance, u,
tmp, and m denote identifiers, r denotes a value of X&, t denotes a value of
value type T.
24.1.2 [lib.output.iterators] para 1: A class or a built-in type X satisfies
the requirements of an output iterator if X is an Assignable type (23.1) and
also the following expressions are valid, as shown in Table 73:
Table 73-Output iterator requirements
expression return type ...
*a = t result is not used
Now, in the light of the above, let's look what 24.3.1
[lib.iterator.traits], para 1 says:
To implement algorithms only in terms of iterators, it is often necessary to
determine the value and difference types that correspond to a particular
iterator type. Accordingly, it is required that if Iterator is the type of
an iterator, the types
be defined as the iterator's difference type, value type and iterator
category, respectively. In the case of an output iterator, the types
are both defined as void.
So it _does not_ really say that value type of an output iterator is void.
What it says is that the "iterator_traits<Iterator>::value_type" typedef is
a synonym for void.
IMO it's kind of odd - value type of an output iterator is not void, but
"iterator_traits<Iterator>::value_type" is required to be a synonym for
void. That's even more strange, it seems like this is an intentional
decision, so I wonder if anybody knows a rationale (if the above analysis is
Hmm.. just noticed that the discussion more and more drifts to something
more appropriate for comp.std.c++ than for this list :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk