Re: reinterpret_cast<int&<( int* ) -- Odd behavior
* joshuamaurice@gmail.com:
On Apr 3, 9:05 pm, blargg <blargg....@gishpuppy.com> wrote:
People seem to be getting confused with casts to a reference type.
Something like
reinterpret_cast<T&> (obj)
is nearly equivalent to
(*reinterpret_cast<T*> (&obj))
if that helps reason more clearly about it.
No. Just no. No at this entire thread.
That may be how it's implemented on some systems, and perhaps it is
interesting to try for fun, but to write any sort of real code, do not
do this.
I interpret the above as saying that the "nearly equivalent" is wrong in the
direction that any equivalence is merely how the particular implementation
does
it, if it does.
And if that interpretation is correct, then your stance on that is
incorrect,
because the standard /guarantees/ this equivalence in ?5.2.10/10.
So the original statement is wrong, but in the other direction: the word
"nearly" should be "exactly". :-)
[snip]
Let me again emphasize that for pretty much all code, if you're
writing a reinterpret_cast, or a C-style cast which cannot be replaced
with a static_cast, then your code probably has undefined behavior.
Agreed regarding the formal for portability.
However, to take a concrete example, in Windows programming you often have
to
reinterpret_cast (or use a C style cast to do the same), because most of the
API
routines' formal arguments are designed for C -- wrong types for C++!
It's in practice well defined behavior because it's defined by the system.
Any
compiler that did something funny, even if allowed to do so by the standard,
would just not make it in the marketplace. So it's just formally undefined.
reinterpret_cast has no defined behavior.
Again, sorry, but that's incorrect, even regarding the purely formal.
First of all, the standard guarantees in ?5.2.10/7 that round-trip
conversion of
pointers using reinterpret_cast yields the original pointer.
Then -- but here we're up against an inconsistency in the standard -- in
?9.2/17 the standard guarantees that a pointer to a POD struct, suitably
converted via reinterpret_cast, points the struct's first member. This is
presumably in support of an old C technique for emulating inheritance. It's
useful for dealing with C interface that are based on such techniques.
The reason it is an inconsistency is that ?5.2.10/7 maintains that all other
reinterpret_cast pointer conversions than the roundtrip one, are
unspecified.
But, considering the potentially large amounts of code Out There(TM) that
relies
on the ?9.2/17 guarantee, and also considering that a formally guaranteed
behavior can't be unspecified, it is IMHO ?5.2.10/7 that is in error.
It's a myth that
reinterpret_cast is a portable construct with certain defined behavior
according to the C++ standard.
I agree. :-)
(Yes, casting to char* and unsigned char* is the exception. Casting
back to any other type is not. If you don't know what this exception
is, pretend I didn't say anything.)
I'm sorry, but casting to char* is, AFAIK, not formally an exception. One
might
argue that it "should" be an exception because otherwise the only way to
copy a
POD object to an array of char (or unsigned char) and back again would be
via
memcpy, whose internal magic could then not be duplicated portably in a
user-defined routine. However, this ability is very strongly implied by
?9.2/17
mentioned above. It would take a perverse implementation to ignore the
non-normative note in that paragraph that it implies no padding at the start
of
a POD struct, and do type-specific things. So, taking the stance that the
first
member of a POD struct /could/ be a char, say, and reasonably assuming that
the
implementation is not perverse in the sense outlined here, one has a
practical
guarantee for char*, and indeed for any other POD type!
Summing up that logic:
* The formal guarantee for casting to char* is a myth.
* But ?9.2/17 implies an in-practice guarantee for any POD*.
Also, never use C-style casts in C++ code.
I used to agree 100% with that.
However, trying to write introductionary material for novices it seems
wholly
wrong to introduce general casts at an early point.
Instead, where required, I've found it convenient to use the pseudo
constructor
notation T(x) for built-in non-pointer types (I'd write just "built-in"
except
it seems that the standard extends the meaning of that term to cover
pointers).
And this resolves to a C style cast.
So, current stance is, no C style casts except the pseudo constructor
notation
for built-in non pointer types.
There is however one thing that can be achieved by a C style cast that can't
be
achieved by any of the named C++ casts, namely accessing an otherwise
inaccessible base.
One might argue that that's so dirty that one shouldn't do it, but I guess
that
the capability is there in the language for a reason, that in some situation
(which I can't quite imagine) it's practically necessary.
Sometimes the C-style cast
is equivalent to a reinterpret_cast, and thus it has all of the
undefined baggage to go with it. The C-style cast's behavior changes
if the full definitions of the types are in scope or just forward
declarations. For example, someone adding or removing a header from a
header from a header which your cpp file includes can \silently\
change the behavior of your C-style cast and break your code. No
errors. No warnings. Nothing.
Good point.
I don't think I've seen it before.
*Noting*.
Cheers, & hth.,
- Alf
--
Due to hosting requirements I need visits to <url:
http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]