Boost logo

Boost :

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.
> Dave,
> would you please stop barking at anyone who dares to use
> reinterpret_cast?

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

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

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] *

Boost list run by bdawes at, gregod at, cpdaniel at, john at