Re: [boost] Re: [smart_ptr] const-correctness as function argument

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-07 03:51:06

"Schoenborn, Oliver" wrote:
> 
> > From: Dave Abrahams
> > > From: "Larry Evans" <jcampbell3_at_[hidden]>
> > >
> > > >David B. Held wrote:
> > > >
> > > > >Deriving from ptr<T const> is a weird beast.  For instance, if you
> declare
> > > > >T* p_; in ptr<T const>, for some reason, it is not visible in ptr<T>,
> > > >
> > > >I'm totally surprised!
> >
> > It's a dependent base class. A conforming compiler will only
> > find it with qualification, e.g.
> >
> >     this->p_
> 
> I'm totally surprised too. This means that gcc 2.96, 3.2, and SGI's MipsPro
> CC are non standard in this regard, which is possible I guess. That said, I
> still don't see why the code that Dave Held wrote would require this->p_
> (how is ptr<T const> a dependent base class?).

I haven't followed the discussion closely, so please forgive if this has
been suggested before or if I misunderstood the problem. You want ptr< T
> to be usable as a ptr< const T >? What about:

template< typename T > class ptr
{
  ...

public:
  operator const ptr< const T >&() const
  {
    return reinterpret_cast< const ptr< const T  >& >( *this );
  }

  ...
};

Or is reinterpret_cast considered too dangerous/non-portable/...? For my
own pointer-class, this works well (GCC 3.2).

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de