From: Richard Peters (R.A.Peters_at_[hidden])
Date: 2002-06-13 08:09:24
----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Damien Fisher" <damien_at_[hidden]>
> > If the iterator writes the values back upon destruction, then the value
> > of bs[5] here will be 1, not 0. This strikes me as really
> > weird...surely this isn't standards conforming???
>
> I think it's weird, but might be conforming. Certainly the iterators by
> themselves are conforming. I don't think the standard says very much about
> the relationship between a container and its iterators. It depends how
> strictly you want to read statements such as "begin() returns an iterator
> referring to the first element in the container".
>
> -Dave
Then isn't this a defect in the standard? If other containers would implement this
behaviour, and would still be standard conforming, then I suspect a lot of programs
would break.
btw, I'm wondering the following:
Currently, a forward iterator a of type X must satisfy that *a returns a value of
type T&, where std::iterator_traits<X>::value_type == T.
What would happen if that requirement is changed so that *a returns a value of type
R, where std::iterator_traits<X>::reference == R, and with the reference having only
a few requirements, like take an r of type R and t of type T, then r = t and t = r
are both defined, but T& t2 = &r wouldn't be. Likewise, the requirement that for a
container with type X, X::reference returns an lvalue of T, could be changed to
X::reference returns a thing that only has to support r = t and t = r as above. That
would make a vector<bool> possible in the way it is implemented at the moment,
right? Could this approach work?
Richard Peters