Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-25 17:06:21


----- Original Message -----
From: "Thomas Witt" <witt_at_[hidden]>
> On Friday 25 January 2002 15:10, you wrote:
> > ----- Original Message -----
> > > My personal opinion is that an iterator_adaptor that exposes its base
> > > iterator is dangerous and error prone. Thank of an cyclic iterator
that
> >
> > wraps
> >
> > > around when it encounters the end iterator of the sequence. You can
> > > safely assume that this iterator is always dereferencable unless
somebody
> > > fiddles with base(). The same problem applies to any adaptor that
> > > modifies the sequencing behaviour.
> >
> > Yes, I understand the problem.
> >
> > However, since so few compilers support friend templates, I don't see an
> > easy solution to that other than saying "don't touch". Do you?
> >
>
> You are confusing me.
>
> For me this is a friend template
>
> class A
> {
> template <class T> friend class B;
> };
>
> but we need:
>
> template <class T>
> class C
> {
> friend class T;
> };
>
> Though gcc-2.95.3 and edg in ms mode accept
>
> template <class T>
> class C
> {
> friend T;
> };
>
> I think neither this nor the solution above is legal with regard to the
> standard. To be more accurate it looks like this problem is not covered by
> the standard.
>
> To me it feels like an omission. Anyway if it is so we wont be able to fix
it
> any time soon.

I agree that these are illegal. I was talking about the operator function
templates, with an eye towards establishing a private base class for
iterator_adaptor<> which had a public mutable base() function; the operators
would need to pass the base class to the policies. To do that, they would
need to be friends. I think the best we can do right now is to fix the
documentation. Would you like to submit a patch?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk