CODEWITHSUNDEEP
c++bit-manipulation
code
code

Reputation: 5642

Extracting two signed integers from one given integer?

I have the following structure:

struct
{
   int a:4;
   int b:7;
   int c:21;
} example;

I would like to combine a and b to form an integer d in C++. For instance, I would like the bit values of a to be on the left of the bit values of b in order to form integer d. How is this implemented in c++?

Example:

a= 1001

b = 1010101

I would like int d = 10011010101 xxxxxxxxxxxxxxxxxxxxx

where x can be 21 bits that belonged to d previously. I would like the values of a and b to be put in bit positions 0-3 and 4-10 respectively since a occupies the first 4 bits and b occupies the next 7 bits in the struct "example".

The part that I am confused about is that variable a and variable b both have a "sign" bit at the most significant bit. Does this affect the outcome? Are all bits in variable a and variable b used in the end result for integer d? Will integer d look like a concatenation of variable a's bits and variable b's bits?

Thanks

Upvotes: 0

Views: 141

Answers (1)

Jonathan Leffler
Jonathan Leffler

Reputation: 754520

Note that whether an int bit-field is signed or unsigned is implementation-defined. The C++ standard says this, and the C standard achieves the same net result with different wording:

ISO/IEC 14882:2011 — C++

§7.1.6.2 Simple type specifiers

¶3 ... [ Note: It is implementation-defined whether objects of char type and certain bit-fields (9.6) are represented as signed or unsigned quantities. The signed specifier forces char objects and bit-fields to be signed; it is redundant in other contexts. —end note ]

§9.6 Bit-fields

¶3 ... A bit-field shall have integral or enumeration type (3.9.1). It is implementation-defined whether a plain (neither explicitly signed nor unsigned) char, short, int, long, or long long bit-field is signed or unsigned.

ISO/IEC 9899:2011 — C

§6.7.2.1 Structure and union specifiers

¶10 A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits.125)

125) As specified in 6.7.2 above, if the actual type specifier used is int or a typedef-name defined as int, then it is implementation-defined whether the bit-field is signed or unsigned.

§6.7.2 Type specifiers

¶5 ... for bit-fields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int.

The context of §6.7.2 shows that int can be combined with short, long etc and the rule will apply; C++ specifies that a bit more clearly. The signedness of plain char is implementation-defined already, of course.

Unsigned bit-fields

If the type of the bit-fields are unsigned, then the expression is fairly straight-forward:

int d = (example.a << 7) | example.b;

Signed bit-fields

If the values are signed, then you have a major interpretation exercise to undertake, deciding what the value should be if example.a is negative and example.b is positive, or vice versa. To some extent, the problem arises even if the values are both negative or both positive.

Suppose example.a = 7; and example.b = 12; — what should be the value of d? Probably the same expression applies, but you could argue that it would be better to shift by 1 fewer places:

assert(example.a >= 0 && example.b >= 0);
int d = (example.a << 6) | example.b;      // Alternative interpretation

The other cases are left for you to decide; it depends on the interpretation you want to place on the values. For example:

int d = ((example.a & 0x0F) << 7) | (example.b & 0x7F);

This forces the signed values to be treated as unsigned. It probably isn't what you're after.

Modified question

example.a = 1001     // binary

example.b = 1010101  // binary

d = 10011010101 xxxxxxxxxxxxxxxxxxxxx

where x can be 21 bits that belonged to d previously.

For this to work, then you need:

  d = (d & 0x001FFFFF) | ((((example.a & 0x0F) << 7) | (example.b & 0x7F)) << 21);

You probably can use fewer parentheses; I'm not sure I'd risk doing so.

Union

However, with this revised specification, you might well be tempted to look at a union such as:

union u
{
    struct
    {
       int a:4;
       int b:7;
       int c:21;
    } y;
    int x;
} example;

However, the layout of the bits in the bit-fields w.r.t the bits in the int x; is not specified (they could be most significant bits first or least significant bits first), and there are always mutterings about 'if you access a value in a union that wasn't the last one assigned to you invoke undefined behaviour'. Thus you have multiple platform-defined aspects of the bit field to deal with. In fact, this sort of conundrum generally means that bit-fields are closely tied to one specific type of machine (CPU) and compiler and operating system. They are very, very non-portable at the level of detail you're after.

Upvotes: 2

Related Questions