Bool type problem

[2kaud]

Oh wow! I had no idea!

Oh yes - bitfields are real fun!

The interesting thing is that you re-arrange the bit fields in the struct then the size can be dramatically reduced. If the struct in post #15 is re-arranaged to be

struct S
{
	char a01 :1;
	char a03 :1;
	char a05 :1;
	char a07 :1;
	char a09 :1;
	char a11 :1;
	char a13 :1;
	char a15 :1;
	char a17 :1;
	char a19 :1;
	int  a02 :1;
	int  a04 :1;
	int  a06 :1;
	int  a08 :1;
	int  a10 :1;
	int  a12 :1;
	int  a14 :1;
	int  a16 :1;
	int  a18 :1;
};

ie all the char first then the int then the size comes down to 8 (VS2013)! A factor of 10 reduction.

[JohnW@Wessex]

...because on that particular compiler, an int is 128bytes (1024bits). yes, such beasts do exist.

I've worked on a DSP platform where there was no such thing as an 8 bit type.

[OReubens]

This print 80. 80 bytes! For 20 bits!

I know for a fact nobody in my organization knows about this, and that we probably have very bloated structs in our code.

Nobody ever checks anything with static asserts...

Heh, feel the headache yet ?

At the company we have a lot of code that does bit packing explicitely by doing the masking and shifting "the hard way".
Pretty much every new recruit eventually comes with the urge to "oh wow you guys are retards for doing this, bitfields are so much easier".

I then give them "the bitfield challenge".
You can only ever take this challenge once during your career at our company. (once you've taken it, you know the answers).
Get it right, and you earn the right to use bit fields wherever you want.
Get it wrong, and you receive the "I failed the bitfield challenge Cup", which you have to prominently display on your desk, until the next challenger fails and takes it from you.

the challenge is 10 "easy" questions about bit fields, you are required to get a perfect score.

The count is 129 challengers. All have failed. The last challenger is now the "proud" owner of the cup for 1 year and 76 days.


---
Your bitfield is also seriously flawed.
int a : 1;
this has a guaranteed/portable range of 0 to 0.
so it's essentially a totally pointless bitfield, or at the very least, it's only going to work on your specific compiler where it may non portably either hold -1 to 0 or 0 to 1.

still not feeling the headache ?

[OReubens]

I've worked on a DSP platform where there was no such thing as an 8 bit type.

oh yes, that's a mistake plenty people make when they do "portable" C/C++: Assuming that a "char" or 'byte' has 8 bits.
the only guarantee you get from C++ is that it's AT LEAST 8 bits. It could be anything equal or lager than 8.
regardless of how many bits it is, it's sizeof(char) is Always 1.

I've seen several platforms where it's 9, 10 and 12 bits, and even one where it's 64, and yes, that "other one" where a char is 1024 bits.

Always fun seeing people get total brain meltdown when they need to deal with a compiler where
sizeof(char) = 1
sizeof(short) = 1
sizeof(int) = 1
sizeof(long) = 1
sizeof(float) = 1
sizeof(double) = 1
but where each of those is "128 bytes"
it's particularly confusing because the platform does indeed know and handle bytes being 8 bits as a distinct type in the CPU.
But any and all addressing can only be done using multiples of 128 bytes.
for C++ to conform to the standard, this means the compiler needs to see those 128bytes as a single 'char', or 'byte' type.
it also means the C++ compiler can at times be horribad for performance, because it can't make use of the smaller CPU types.

[2kaud]

the challenge is 10 "easy" questions about bit fields

Isn't that an oxymoron?

[OReubens]

Well there's quotes around the easy for a reason.

the questions appear simple enough, and I usually get the answer sheet back within 15minutes. That alone already tells me they'll have failed. ;-)

[monarch_dodra]

You have picked my interest. I would like to take that test. Could you PM me a copy (I won't share with anyone)? If I fail, I'll wear the crown in my sig

[OReubens]

well, considering #15
you would already have failed it

Will try to do it later, don't have access to it from here.

[monarch_dodra]

well, considering #15
you would already have failed it

Well, I wasn't yet ready to take it back then, and made no assumptions that I'd nail the test.

I've since studied up on them, and would like to know what I *still* don't know

[razzle]

Nope, it is in the spec, but you won't find it if you only look at the specific topic about bitfields because it's not in there.

So where is it then? Show us!

I am going to accept that I might be incorrectly interpreting the part I'm alluding to, but if so, every single C and C++ compiler I've used to date (and that's a considerable amount) seem to be interpreting that part in exactly the same way.

C++ is not defined by its compilers.

C++ is not defined by your personal experience or anyone else's.

C++ is defined by a standard.

Do you hear? By a standard! Get it!

[2kaud]

By a standard!

Which says that in some cases behaviour is undefined so in those cases we have the behaviour of c++ as set by its compilers

[Philip Nicoletti]

I do have support in the standard. Feel free to find it. Or alternatively,
show me the 32-bit or higher compiler where it's less than 8.

g++

Results for the sizeof the struct in post # 1:

* Suse Linux / g++ 4.4.1 : 4
* Suse Linux / g++ 4.6.1 : 4
* MinGW with g++ 4.6.1 : 4
* MinGW with g++ 4.8.1 (default compiler options) : 8 (-mms-bitfields is the default)
* MinGW with g++ 4.8.1 (with -mno-ms-bitfields) : 4

Results for the sizeof the struct in post # 15:

* Suse Linux / g++ 4.4.1 : 4
* Suse Linux / g++ 4.6.1 : 4
* MinGW with g++ 4.6.1 : 4
* MinGW with g++ 4.8.1 (default compiler options) : 80 (-mms-bitfields is the default)
* MinGW with g++ 4.8.1 (with -mno-ms-bitfields) : 4 (-mms-bitfields is the default)

after 4.7, the default bit field packing is to use the one
compatible with the Microsoft compiler (-mms-bitfields).

For a discussion see : https://gcc.gnu.org/onlinedocs/gcc/V...ttributes.html
This link also gives a nice discussion on the rules the MS compiler uses.

Also, I don't see how g++ could be considered "incorrect"
based on 1.7.4 and 9.6.1 in the standard. Maybe I am missing
something. If so, could someone point to the section(s) ?

[OReubens]

Also, I don't see how g++ could be considered "incorrect"
based on 1.7.4 and 9.6.1 in the standard. Maybe I am missing
something. If so, could someone point to the section(s) ?

Because it violates the rule that the unsigned int isn't following the alignment requirements for an unsigned int (?).