Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-07 12:27:30

"Schoenborn, Oliver" wrote:
> > From: Daniel Frey [mailto:daniel.frey_at_[hidden]]
> >
> > My pointer-class contains only a single data element, which is a real
> > pointer to T, hence a 'T*' or a 'const T*'. I cannot imagine any sane
> > compiler to create different layouts in this case.
> After the reinterpret cast, the compiler uses a given area of memory as
> though it were a ptr<const T> rather than a ptr<T>. I believe this is not
> just data, it's the associated methods too. Let's say you call ptr<const

I don't think it's "the methods", only the vtable may be important. The
methods are not stored in the object in general - this would be a
ridiculous waste of memory. Instead, the methods have an (invisible)
pointer to the object they work on. And here you will call a method
which expects a ptr<const T> with a pointer to some memory which was
generated to be a ptr<T>. This shouldn't be a problem for our case...

> T>::method() on the reinterpreted object. And say the ptr<const T> has not
> been used in another part of your translation unit. Does the compiler
> instantiate ptr<const T>::method(), or does the reinterpret cast also tell

I think the compiler will instantiate ptr<const T>. What else should it
do? But this is not a problem here.

> it that this method already exists (because it was instantiated for ptr<T>)?
> The latter seems unlikely if the compiler keeps some sort of name table, and
> seems likely only if compiler actually looks at what object code it has
> produced in memory.

Even if the compiler can find out that it could use the (const) method
of ptr<T> although as has a ptr<const T>, this would work. This would be
a completly transparent optimization. Or were you trying to make some
point I haven't seen?

> > It's not the methods, it's the object that they expect. As described in
> > my other post, it may be a problem if you have a vtbl, otherwise, you
> > can call a method which has been instantiated for a 'const T*' on a
> > reinterpretated 'T*' and the other way is not possible as there is no
> > cast from ptr< const T > to ptr< T >.
> There's a big different between reinterpreting a T* to a const T*, and
> reinterpreting a class<T*> to a class<const T*>, so I don't understand what
> you mean there.

I mean that the function that get's a ptr<const T> which is really a
ptr<T> will try to address the member T* inside ptr<T> as if it is a
const T* - and that shouldn't be a problem IMHO. If you would cast a
ptr<const T> to ptr<T> and you'd call a member function on it, you
effectivly address a 'const T*' inside of ptr<const T> as a T*. Hope
it's a bit clearer now :)

Regards, Daniel

Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at