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 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".
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk