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

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-07 12:08:18

Daniel Frey <daniel.frey_at_[hidden]> writes:

> David Abrahams wrote:
> > 
> > Daniel Frey <daniel.frey_at_[hidden]> writes:
> > 
> > >
> > > I'm still interested in an example where it fails, as all real-world
> > > code works fine for me :)
> > 
> > Why not just use static_cast through void*, since that not only works
> > in the real world but is guaranteed to work according to the standard?
> 
> Is it? As far as I understand the problem, it makes no difference - if I
> use static_cast, the same problems could occur. The underlying problem
> with casts is always the same: You tell the compiler that you know
> better. You actually have to force the compiler to accept an object of
> type X as type Y and I can't see how static_cast could be any
> better/different than reinterpret_cast here. Indeed I had some problems
> with static_cast creating temporary objects - which is what I definitely
> don't intended - when playing with my pointer class. If you have some
> insight about why static_cast could do better than reinterpret_cast
> here, I'd be happy if you share your wisdom with me. :)

Well, I don't know about your problem domain, but AFAICT, there's
never an excuse for reinterpret_cast<>. Its effects are
implementation-defined, whereas the behavior of static_cast<> is
always defined. As for creating temporary objects, if you're
static_cast-ing pointers, it can only create temporary pointers. I'm
sure that's not a problem for you, is it?

-- 
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com