Re: Type length in bits?
"Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> schrieb im
Newsbeitrag news:ipdmrc$fu3$1@dont-email.me...
* Matthias Hofmann, on 29.04.2011 02:58:
// Determine the number of bits used for the value representation.
const int num_bits = sizeof ( T ) * std::numeric_limits<T>::digits;
Remove the `sizeof(T)*` and the above is OK.
Oops. Seems like I still had CHAR_BIT on my mind when I wrote this.
// The bit pattern of x will probably be all
// zeros except for the least significant bit.
T x = 1;
The value representation is 000....01 with all representations permitted
by the
standard for a built-in type.
// Shift the least significant bit out of range of
// the bits used for the value representation.
x<<= num_bits;
It's apparently OK by itself but if you use that "value", then you have
UB.
So I would probably have to mask the object representation bits off after
shifting and then assign to x:
x = x << num_bits & 0xFFFF;
Is this defined behaviour? I guess the expression "x << num_bits" is subject
to integral promotion, and the resulting "value" is then used in connection
with the bitwise AND operation. So what if integral promotion results in the
same type? Doesn't this lead to the same problem?
Let us assume that T is a 18 bit integer type that uses 16 bits for the
value representation like this ( O = object representation only, V =
value
representation):
OOVVVVVVVVVVVVVVVV
The first line will set the value of num_bits to 16. The second line will
initialize x to contain a value like ( U = undefined ):
UU0000000000000001
The thirs line will shift the least significant bit 16 positions to the
left, so it ends up at the position of the least significant bit used for
the object representation only:
U10000000000000000
Now what is the value of x according to the standard? Am I right in
thinking
that it evaluates to zero, because any bits that are shifted out of range
are simply discarded? Or is it possible that the bit pattern now is a
trap
representation on certain systems, resulting in undefined behaviour?
A trap is possible.
It's UB.
But most importantly, when was the last time you had to worry about this?
<g>
Actually you should have to worry each time you are using the shift
operator:
int f( int xi )
{
return x <<= 1;
}
If an int is a type like in my previous example, then using the return value
of f() should be undefined behaviour, because some of the bits from the
value representation of x are very likely to be shifted out of range and end
up in the "object representation only" section.
--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]