Bart van Ingen Schenau posted:

> Note: The only way that you can find out where the padding bits are
> located within an unsigned short object, is by looking at that object
> as an array of unsigned char. The normal bitwise operations will act
> as-if the 21 data bits are contiguous.

So let's say that someone says to us:

    A short is 32-Bit on this system.

Our first thought is: Are they talking 32 value bits, or 32 object bits?

I'm going to try write portable code for determining the amount of value=20
bits for an unsigned integer type:

template<class T>
unsigned short ValBits()
{
    unsigned short val_bits =3D 1U;
   =20
    T const one =3D 1U; /* To bit-shift by 1 */

    T x_old =3D 1U;

    T x_new =3D 1U;

    while ( (x_new <<=3D one ) > x_old )
    {
        x_old =3D x_new;
        ++val_bits;
    }

    return val_bits;
}


Which brings me on to the following:

We're guaranteed the following in C++:

char: 8-Bit atleast.

short: 16-Bit atleast.

int: 16-Bit atleast.

long: 32-Bit atleast.


We know that we have 8 value bits with a "char"... but does the Standard=20
explicitly state that for the other unsigned integer types, that the figu=
re=20
refers to value bits, and not object representation bits?

If people want a 16-Bit bitmask in portable code, they commonly just type=
:

unsigned short x;


Is this perfectly okay? Or is it possible that we only have 16 object=20
representation bits... ? My guess is that our minimum values bits is=20
guaranteed.


-Tom=E1s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tom   s" wrote:
> Bart van Ingen Schenau posted:
>
> > Note: The only way that you can find out where the padding bits are
> > located within an unsigned short object, is by looking at that object
> > as an array of unsigned char. The normal bitwise operations will act
> > as-if the 21 data bits are contiguous.
>
> So let's say that someone says to us:
>
>     A short is 32-Bit on this system.
>
> Our first thought is: Are they talking 32 value bits, or 32 object bits?

That shouldn't be your second thought. Systems where the number of
value bits and the number of object bits differ are rare. Your first
thought should be that both the number of value bits and the number of
object bits is probably the same.

..
> We're guaranteed the following in C++:
>
> char: 8-Bit atleast.
>
> short: 16-Bit atleast.
>
> int: 16-Bit atleast.
>
> long: 32-Bit atleast.

The limits are actually defined in terms of the values of the *_MIN and
*_MAX macros. Given that those macros define the limits on valid values
of the corresponding type, the bit counts you list above refer to the
number of bits in the value representation, not the number in the
object representation.

> We know that we have 8 value bits with a "char"... but does the Standard
> explicitly state that for the other unsigned integer types, that the figure
> refers to value bits, and not object representation bits?

No. The standard doesn't define a number of bits, it just defines upper
and lower limits on values.

> If people want a 16-Bit bitmask in portable code, they commonly just type:
>
> unsigned short x;
>
>
> Is this perfectly okay?

That depends upon the sense in which you wish it to be 16 bits. That
type is guranteed to have at least 16 value bits, but it could have
more. The number of bits in the object representation is at least as
large at the number of value bits, but could be larger. Therefore, the
above code is "OK", in any context where the gurantees I just stated
are adequate. If you need, for example, an exactly 16-bit type, for a
hardware interface, there's no guarantee that "unsigned short" is that
type. In any context where there's a need for a hardware interface with
exactly 16 bits, you're virtually guaranteed (by the market, not by the
standard) that at least one of the standard types is 16 bits, but it
might be unsigned char rather than unsigned short.

> ... Or is it possible that we only have 16 object
> representation bits... ? My guess is that our minimum values bits is
> guaranteed.

True, but only indirectly, as described above.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]