Re: [boost] boost CVS changes

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
/any/
> > 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:

------------
Hi Matt,

Here's a new LWG issue, I think. Please check for reasonableness, as I am
sick.

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
places:

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

and

  *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
iterator_traits<X>::value_type
3. Fix 24.3.1/1 so that an output iterator can have a useful value type

-Dave