initializing a POD bitfield struct

[monarch_dodra]

I'm wondering what is the "best" way to initialize a bitfield struct. I have this bitfield, defined as:

struct S
{
    unsigned int a : 1;
    unsigned int b : 1;
};

If I'm "using" the bitfield, I can initialize it easily when declaring it, as so:

int main()
{
    S s = {0};
}

Now, the issue I'm facing is that I want to embed S inside another struct, which I'll name "outer". EG:

struct Outer
{
    S s;
};

I'm wondering what the "best" way to have Outer initialize S is? I've seen a lot of people use the "union" approach:

struct Outer
{
    Outer()
    {
        u.all = 0;
    }
    union
    {
        unsigned char all;
        S s;
    } u;
};

but:

1. This adds an extra field depth (the union's u)
2. Does bit hacking, in a way (is the bitfield as large as my field?)

Ideally, I'd have wanted to initialize the field in my constructor, as so:

Outer::Outer() : s({0})

However, this would appear to be a C++11 feature only.

I have, however, "observed" that by simply "empty constructing" s, eg:

Outer::Outer() : s(){} //Initialize s ?
vs
Outer::Outer(){}

Then my bitfield "appears" initialized.

I'd like to go with this solution, but I'm unsure if I'm just "lucky" in my observations, or if this actually guarantees my bitfield is initialized. Is it?

[2kaud]

Why not define a constructor for S that performs the initialisation?

#include <iostream>
using namespace std;

struct S
{
    unsigned int a : 1;
    unsigned int b : 1;

	S() : a(0), b(0) {cout << "init S\n";}
};

struct Outer
{
    S s;
};


int main()
{
Outer O;
}

[monarch_dodra]

Why not define a constructor for S that performs the initialisation?

Well, S isn't necessarily something I own. And if at all possible, I'd rather it stay a POD.

[superbonzo]

I'd like to go with this solution, but I'm unsure if I'm just "lucky" in my observations, or if this actually guarantees my bitfield is initialized. Is it?

yes it is ( or not, see below ), s() ( and s{} in c++11 ) denotes value-initialization that for POD types means zero-initialization.

That said, AFAIR not all c++03 compilers actually follow the rules when subobjects are concerned, take a look at boost doc here for further details ( and a workaround ).

[OReubens]

A bitfield is for most intents and purposes the same as the type it's a number of bits from, as such, initialisation, and aggregation happens exactly the same way as if they weren't bitfields.
so.

struct Sb
{
    unsigned int a : 1;
    unsigned int b : 1;
};
struct S
{
    unsigned int a;
    unsigned int b;
};

In the above, Sb and S are syntactically equivalent, there's a functional difference in that S.a and S.b have a reduced range of values they can hold. And there is of course a difference in actual memory storage layout.

you can aggregate initialise the same way as any other struct. The compiler should warn about any values going out of range.

S s = { 15, 3 };  // initialize s.a to 15, and s.b to 3
Sb sb = { 0, 1 }; // inisialize sb.a to 0 and sb.b to 1

If a struct/class is part of another struct/class and all rules and requirements of aggregate types apply (applied recursively to members and arrays), then initialisation is done in the usual way.

struct IntDoubleSandSb
{
  int i;
  double d;
  S s;
  Sb sb;
};

// initialized as such
IntDoubleSandSb foo = { 88, 3.1415, { 15,3 }, { 0,1} }; //i=88, d=3.1415, s and sb initialized like above.

As you can see, there is no syntactical difference in how to initialize a bitfield vs normal non-bitfield members. ALl normal rules for aggregate type initialization apply (recurcively).


Note that there is no guarantee about how bits in a bitfield get assigned within their larger type. some compilers to it high to low, some low to high. If you need a specific set of bits and need this to be portable, then use explicit masking, not bitfields.

[monarch_dodra]

yes it is ( or not, see below ), s() ( and s{} in c++11 ) denotes value-initialization that for POD types means zero-initialization.

That said, AFAIR not all c++03 compilers actually follow the rules when subobjects are concerned, take a look at boost doc here for further details ( and a workaround ).

Nice link.

A bitfield is for most intents and purposes the same as the type it's a number of bits from, as such, initialisation, and aggregation happens exactly the same way as if they weren't bitfields....

Thank you very much (both). That was a real complete and helpful answer.