|
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