Re: static_cast vs. reinterpret_cast
On Sep 27, 12:46 pm, Kurt Stege <kurt.st...@siemens.com> wrote:
Alan McKenney wrote:
Unfortunately, C++ considers "char" and "unsigned char"
to be unrelated types as far as pointers to them go, so you can't
do static_cast<const char *> on a "const unsigned char *"
Yes...
So far, I know of no alternative that doesn't copy the data
I am using in these cases static cast(s), however, it does
not make things really better:
static_cast<const char *>(static_cast<const void *>(...))
This gets rid of the reinterpret cast, and covers the undefined
behaviour a little bit ;-)
There was a recent thread on this, and the general
conclusion was that your double static_cast was no
better than reinterpret_cast<> in terms
how well-defined the behavior is.
Actually, I would expect the simple reinterpret_cast<>
to be more reliable, since it provides the information
(source and target type) to the compiler in a more
direct way. If it's a cast that the compiler writers
are familiar with (such as unsigned T* <-> signed T*
or T* <-> char*), they are more likely to make sure it
works as expected.
I also believe that "undefined behavior" is, if actually
in the Standard, misleading. I would think that
"implementation-defined behavior" is closer
to the truth, if we allow the implementation
definition to say "not allowed" in some cases.
The whole point of reinterpret_cast<> is to allow
casts whose behavior the Standard can't define for all
implementations, but which can be used safely if
used with care and some knowledge of the platform
being used.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]