From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-07 06:48:58
----- Original Message -----
From: "John E. Potter" <jpotter_at_[hidden]>
> 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.
> You can't compare output_iterators; so difference_type has no meaning
> => void. 24.3.1 covers the last two.
> > I tend to agree. One could imagine generic output iterators, to which
> > type could be written, but surely that's not a reasonable requirement to
> > impose.
> It's really simple. The only thing you can do is *it = t; ++it. Either
> it works or it doesn't.
> > As a matter of fact, I think the output iterator requirements table is a
> > complete mess. I guess I'm submitting an issue right away.
> Looks good to me. Now, the input iterator table does not even have the
> same format as the others, but that is another subject for another place.
Here's what I wrote to Matt about it:
Here's a new LWG issue, I think. Please check for reasonableness, as I am
Table 73 is confusing at best:
"a = t is equivalent to X(a) = t." ***
According to 24.1/9, t is supposed to be "a value of value type T":
"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."
Now, we can take the idea of an output iterator's value type from one of two
a. 24.1/1 which says "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 iterator", which is clearly wrong for output iterators.
b. 24.3.1/1, which says "In the case of an
output iterator, the types iterator_traits<Iterator>::difference_type
iterator_traits<Iterator>::value_type are both defined as void."
Aside from being useless for generic code (possibly another defect), if we
take interpretation b, the expression *** at the top is meaningless, because
t is void and there are no void objects...
Worse yet, it appears to be suggesting that the output iterator should have
a member function of the form
operator=(const T&) const // note final const!!
Since the expression X(a) creates a temporary.
Finally, output iterators are supposed to support
*a = t
*r++ = t
But what is a reasonable type for t?
A proposed resolution (without language) looks like this:
1. Fix 24.1/1 so that it does not break on output iterators
2. Fix 24.1/9 so that it makes clear that t is of the
3. Fix 24.3.1/1 so that an output iterator can have a useful value type
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk