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

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-07 10:15:34

"Schoenborn, Oliver" wrote:
> 
> > -----Original Message-----
> > From: Daniel Frey [mailto:daniel.frey_at_[hidden]]
> >
> > 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).
> 
> Interesting, I'd like to know if there are any situations where it is not
> safe. Since the member data and functions for T and const T are exactly the
> same perhaps this is safe. But I would guess that unless something like that

The only potential problem could be the vtable, as there might be a
different one for ptr< T > and ptr< const T >. I'm not sure what could
happen if these two are mixed up, it clearly depends on ptr. For my own
classes, this is not a problem as I don't have a vtable and for the
boost pointer classes, I think this is true, too.

> is specified in the standard (about the action of reinterpret_cast on
> template classes of T vs on const T), it's probably non-portable in theory
> (though in practice it may be).

That's the problem: The standard makes reinterpret_cast useless for
people that insist on the standard. When thinking about practice, I
think it is an acceptable risk. Especially as boost is tested for a
given set of compilers, it should be possible to check if it works :)

> Hopefully some of the experts on the list
> will share their opinions. Have you posted this to other newsgroups like
> c.l.cpp.m?

Hm, I think I should do so, but I'll try to make up a better example
first. Thus the post to clc++m may take some time (and I'm pretty busy
right now...)

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