|
Boost : |
From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-16 08:54:06
Peter Dimov writes:
> From: "David Abrahams" <dave_at_[hidden]>
> >
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >
> > > From: "David Abrahams" <dave_at_[hidden]>
> > > >
> > > > Any iterator which stores the referent of its operator* within the
> > > iterator
> > > > object is an example that causes serious memory problems if operator[]
> > > > returns a reference.
> > > >
> > > > That's a legal technique for random-access iterators.
> > > Isn't this a defect report material?
> >
> > I don't know, what would the defect be?
>
> Good question. There is no defect in the strict sense of the word. But do
> you like the current situation, where you are forced to cripple all
> iterators generated by the library just because someone _might_ do an
> iterator that returns by value from []?
Can't we check whether [] returns a reference, somehow? It's not like we're
asking "what is the return value?", just is it T& or not, for known T,
something like:
template<typename T,typename IteratorType>
struct checkSubscriptReturnIsRefToT
{
template<typename V>
Big check(T& (IteratorType::*)(V));
Small check(...);
static const bool
result=(sizeof(check(&IteratorType::operator[])==sizeof(Big));
};
Obviously, we need to cope with const, volatile and const volatile operator[],
and versions taking different types of parameter, but I'm sure you can fill in
the details.
Anthony
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk