From: David Abrahams (dave_at_[hidden])
Date: 2002-10-09 12:31:29
Daniel Frey <daniel.frey_at_[hidden]> writes:
> David Abrahams wrote:
> > Wow, this seems really difficult to grasp, but I can't understand why.
> > 5.2.10 Reinterpret cast
> > ...
> > 3 The mapping performed by reinterpret_cast is
> > implementation-defined. [Note: it might, or might not, produce a
> > ^^^^^^^^^^^^^^^^^^^^^^
> > representation different from the original value. ]
> > That means it does _something_, but only the compiler vendor and those
> > who have read the manual know what it does.
> would you please stop barking at anyone who dares to use
Maybe you should try less-loaded language. Nothing I posted comes
remotely close to "barking". However, people who continue to argue
with what is plainly written in the standard are beginning to try my
> It's easy to cite the standard and tell them "Don't do it!"
I actually never said "don't do it".
> but people don't just use reinterpret_cast to annoy you (Really!
> :). Why not help developing a better solution?
I think that pointing out the issues with reinterpret_cast is helpful
in and of itself. I even went to the trouble to dig up the relevant
> Maybe static_cast is better, but it makes the code unreadable and
> you have to care about too much details, so it needs to be
It's pretty trivial to do, and someone already posted it, and I'm busy
with the boost release at the moment so I don't have time to spend on
it. Furthermore, I'm not actually dissatisfied with the facilities
provided for this by static_cast, so it's not my problem to solve.
> If boost would provide a helper function, the actual code might
> become clearer, as it was the case for "noncopyable", "next/prior"
> and other little helpers. They are all no magic and everyone should
> be able to live without them, but they help to make your code
> shorter and more readable. I suggested a pointer_cast already
OK, so that was you. Great! Why do you expect me to work on the issue?
> , maybe it's even possible to create a "portable_reinterpret_cast"
> which does what people expect when using "reinterpret_cast", but
> with an implementation you could live with. Maybe in the long term,
> reinterpret_cast could even be removed from the language and the
> boost-replacement might be called std::reinterpret_cast by that time
> - who knows...
I'm sure those are all interesting questions for people who care about
them... but that doesn't include me.
-- David Abrahams * Boost Consulting dave_at_[hidden] * http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk