DJ Delorie wrote: >> The "except that" sentence implies the statement above, assuming >> that the pointed-to type does not have stricter alignment. So, if >> casting a 32-bit pointer to int to a 16-bit pointer to char and back >> does not always yield the same value, then something has to give. > > reinterpret_cast doesn't require that the intermediate form have the > same bit pattern.
Exactly so. However, all valid pointers must be handles, so unless the 32-bit address space is "sparse", something will go wrong. > The way I read it, "a pointer" to an object can be converted to "a > pointer" to a different type of object, but as reinterpret_cast > already leaves the const qualifier alone, it seems to be focusing on > the object's type, not the pointer's type. There's no distinction in ISO C++; every object type has exactly one associated pointer type. The point of reinterpret_cast is to let you convert A* to B* where A and B are unrelated object types. It's an operation on pointers, not general objects; for example, you can't do "reinterpret_cast<double>(7)", but you can do "reinterpret_cast<double*>((int*)0))". > If you say C++ doesn't support them, I'll take it out and make it > obvious that C++ doesn't support them, as long as C still supports > them (because I use that feature a lot). I just don't want it to > crash when the user does something that appears to be legal based on > the gcc manual. Good call. I don't feel qualified to comment for C, but for C++, I think it's correct to say that we don't support them. I think we *could* support them, in theory, but that would be a good bit of work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
