Boost logo

Boost :

From: Hillel Y. Sims (hsims_at_[hidden])
Date: 2002-10-07 14:02:18


"David Abrahams" <dave_at_[hidden]> wrote in message
news:uy99a41od.fsf_at_boost-consulting.com...
>
> 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.

I have used reinterpret_cast<> once to provide compile-time switching
between different algorithmic "views" of a database container. Something
like
    enum IterType { ... };
    template <IterType iterType> class Row {
             template <IterType iterType2> operator Row<iterType2>&()
                  { return reinterpret_cast<Row<iterType2>&>(*this); }
    };

I guess I could write that as "return
*static_cast<Row<iterType2>*>(static_cast<void*>(this));" instead (that
hadn't actually occurred to me before). In this case I am not even casting
away or applying constness to the underlying type though, so is there still
a potential problem using reinterpret_cast<> to do this?

thanks,
hys

--
Hillel Y. Sims
FactSet Research Systems
hsims AT factset.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk