Re: Stanard compliant bit-casting
On Mar 11, 1:49 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
reinterpret_cast was not added to the language to support type
punning.
Why was it added to the language, then?
[...]
Finally we have type punning through unions. While explicitly
not supported by the standard(s), it's supported as a compiler
extension by basically every C and C++ compiler. (Confirmation
anyone?)
The only compiler I've seen that documents it as being supported
is g++ (but I've not really looked at all of the documentation).
And even with g++, it depends on the context---there are cases
where it will fail.
From a QoI point of view: if the union or the reinterpret_cast
is visible, I would expect the code to give the expected
results. Any accesses elsewhere, and all bets are off, e.g.:
int f(int* pi, double* pd)
{
int retval = *pi;
*pd = 3.14159;
return retval;
}
int
main()
{
union U { int i; double d; } x;
x.i = 42;
std::cout << f(&x.i, &x.d) << std::endl;
return 0;
}
I would not count on this code outputting 42, regardless of any
guarantees the compiler might give.
[...]
Also, there are plenty of good reasons to do type punning. For
example, games. I'm pretty sure that using a portable UTF8
text format for ints for their network packets would result in
rather unacceptable performance.
So you use any one of a number of binary formats. You still
don't need (nor want) type punning to implement them.
Yes, it carries the problem that a newer compiler, OS, etc.,
may render the communication not compatible, but in certain
contexts this is an acceptable drawback. (Next I'll be hearing
that a first person shooter should send its data over the
network in XML format and should utilize a full XML parser on
the receiver side. / sigh)
What's wrong with XDR?
--
James Kanze