Re: [boost] reinterpret_cast<const shared_ptr<const T>&> [was Re:const-correctness as function argument]

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

"Schoenborn, Oliver" wrote:
> 
> I took a look at the C++ Standard. Paragraph 10 of section 5.2.10 is
> interesting:
> 
> "An lvalue expression of type T1 can be cast to the type "reference to T2"
> if an expression of type "pointer to T1" can be explicitly converted to the
> type "pointer to T2" using a reinterpret_cast. ... The result is an lvalue
> that refers to the same object as the source lvalue, but with a different
> type. No temporary is created, no copy is made, and constructors (12.1) or
> conversion functions (12.3) are not called."

The last sentence is the important one.

> So the reinterpret_cast solution is standard only if there is something in
> the Standard that says that the layout for a class<T> MUST be the same as
> that for class<const T>, which I don't think is the case (though in practice
> it probably ends up like that). Paragraph 10 suggests to me that a

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.

> reinterpret cast of the type discussed is not safe when the two classes are
> separate, ie is only safe when the cast is within an inheritance branch,
> because you can't be sure that the same methods are instantiated in both.

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 >.

> For instance, if you have Base and Derived, then ptr<Derived> may have a
> different set of methods instantiate than ptr<Base>, therefore the
> reinterpret cast is unsafe.

I'm still interested in an example where it fails, as all real-world
code works fine for me :)

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