
On 21.03.2017 21:23, Steven Watanabe via Boost wrote:
what's wrong with struct animal { bool eats_meat : 1; bool eats_grass : 1; bool has_tail : 1; };
There are several reasons I don't like that approach
While declaring a variable of type 'animal' you should always keep in
mind to initialize it with empty initializer
animal a1; // bit fields are not initialized
animal a2{}; // now it's ok, bits are set to zeros
When you want to initialize some fields (eats_grass, has_tail) you have
to write several lines of code
animal a1{};
a1.eats_grass = 1;
a1.has_tail = 1;
Of course, it can be done in one line with initializer list
animal a1{0, 1, 1};
But we don't write a code ones, we are about to support it for a long
time. One day we decided to add a new bit field to structure
struct animal {
bool can_fly : 1; // yeah, somebody puts it on the first position
bool eats_meat : 1;
bool eats_grass : 1;
bool has_tail : 1;
};
What will happen with all of list initializers? There will be bugs we
can't detect at compile time.
animal a1{0, 1, 1}; // now it doesn't work properly
We have to find all of such initializers and rewrite them
animal a1{0, 0, 1, 1};
To prevent this I propose to abstract from strict ordering and use
typed entities
animal a1{flag