From the C++ standard:
5.2.10.3
The mapping performed by reinterpret_cast might, or might not, produce a representation different from the original value.
I've been trained at this very site to believe and repeat this. (Even if it's possibly just trivia). A reinterpret_cast from float* to int* is allowed to produce a different bit pattern. The only guarantee is that reinterpret_cast-ing that result back to float* will produce the original bit pattern.
My question: Does this ever happen? Is there an existing, real-world platform or CPU or compiler that actually reinterpret_casts to a different bit pattern? If not, are there any real-world situations where reinterpret_cast has any runtime overhead?
In all my experience with reinterpret_cast, the cast was a directive to the compiler, not the runtime.
I've worked on platforms where char* was larger than int*,
and on platforms where they had a different layout, even though
the size was the same. Neither of the machines in question are
particularly relevant today, however (although the second, the
PDP-10, was one of the more important machines in its heyday).
It's also conceivable that some compilation modes on an Intel in
native mode (or what used to be called native mode) would
"normalize" pointers in a reinterpret_cast, or even an
implicit conversion, in order to facilitate address comparisons.
It's also conceivable (although I've not seen it) that such
conversions enforce correct alignment, e.g. a conversion from
char* to int* might force the 2 low-order bits to 0. In
practice, however, I don't think, today, that you're likely to
see a reinterpret_cast make any changes between data pointer
types. The issue is more historic. (But I'm not sure about
modern embedded processors. From what I understand, many of them
are word addressing, and so if sizeof(int) != sizeof(char), they're
likely to need a special format to address char.)