On Dec 15, 12:51 am, john <j...@no.spamwr ote:
James Kanze wrote:
Every object is made up of bytes -- *every* object. The
reinterpret cast here is the perfect candidate for the job.
Except that the standard doesn't say so. Practically speaking,
the standard doesn't even guarantee that you can
reinterpret_cas t a char* to an int* without getting a core dump.
Realistically, the standard doesn't say so, because it wants
reinterpret_cas t to be pragmatically useful, and what it takes
to be pragmatically useful depends very much on the machine
architecture. IMHO, the intent is clear, and I don't worry
about using it when I'm working this close to the hardware.
If I recall well from past discussions in clc++,
"reinterpret_ca st<unsigned char *>(&x)" will not work as expected in
multiple inheritance cases (like a class C inheriting from both classes
A and B, while
"static_cast<un signed char *(static_cast<v oid *(&x));" will work.
class A;
class B;
class C: public A, public B
{
// ...
};
For what definition of work? I expect that both
reinterpret_cas t and static_cast will behave more or less
identically here. In both cases, starting from the address of
the complete object, you'll end up with a pointer to the first
byte of the complete object. In both cases, starting with the
address of one of the base classes, you'll get the address of
the first byte of the sub-object.
There may be problems in the case where the compiler has applied
the empty base class optimization, but I would expect the
problems to be present in both cases. And in neither case can
you cast the resulting pointer back to anything but its original
type, and expect to use it. (In general, any time you go
through a void*, you have to be careful of this. It's a
frequent error with callbacks.)
The difference is that in the case of the two static_cast, the
standard requires it to work, where as in the case of
reinterpret_cas t, the standard formally leaves it
"implementa tion defined" (but with a number of indications that
the intent is for it to work).
--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34