Felipe Magno de Almeida wrote:
On Fri, Dec 18, 2009 at 6:11 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Dec 17, 2009 at 11:17 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
[snip]
Really? I thought this was implementation-defined?
Sure, but it is specified that if you reinterpret_cast from T1* to T2*, then reinterpret_cast the resulting T2* back to T1*, you'll get the original value (as long as T2 doesn't have stricter alignment requirements.)
But nothing else is guaranteed. The compiler might very well increment it by one byte when casting to T2 and then decrement it when casting it back. It is perfectly valid behavior for reinterpret_cast.
Maybe, in principle, but if you try to write such a compiler you'll find that it isn't as easy, even if we dismiss C compatibility as a concern and stick to C++03. (In the latest C++0x draft reinterpret_cast for pointers to standard layout types is defined to do the static_cast dance.)
IMO we should be using static_cast<T2*>(static_cast<void*>(x)) which is not implementation-defined.
There isn't much difference. In practice, the two do the same thing. g++ should issue the same warning for both; it doesn't because the current frontend isn't smart enough to see through the intermediate void*.