C++ Weekly – Ep 99 – C++ 20’s Default Bit-field Member Initializers


Hello and welcome to C++ weekly. I’m your host Jason Turner. I am available for on-site training contracting and code reviews so C++ 17 was completed and officially made a standard in 2017 and now the committee has started working on C++ 20 features, and there’s been a few things that have been approved but Obviously we’re not seeing widespread compiler support for these things yet but we do have the opportunity to play with some C++ 20 features and Well, I have the chance to do that so I’m going to do it, so we’ve got the clang trunk build that’s currently available on compiler Explorer and I have enabled -std=c++=2a to a so now we can start playing with C++ 20 features and now they’re saying 2a because of course, there’s no guarantee that will actually see a version of C++ in 2020 but committee has a good track record c++11 Was late c++14 and c++17 came out on time so we expect C++ 20 will probably come out on time so the first feature that I’m going to demonstrate is Initialization of bit fields so this is kind of fascinating to me if we’ve got our struct S And you would be forgiven if you had never used a bit field before But if we wanted to say we’ve got this bit This int i and it takes 3 bits and int j takes 5 bits then We might expect that the size of our struct S is Going to be 1, 1 byte, and let’s see if that’s the case no it is 4 bytes That is because we are getting a padding of size s with 3 bytes to alignment Boundary so this is padding. That’s going to be required for this struct, but it’s getting three bytes of padding Which means that we are actually only using one byte, so if we increase the size of this we expect to see our Padding change, and now it is reporting 23 bits of padding so we have our struct that is effectively 1 byte and It contains these 2 bit fields now before C++20 if we wanted to initialize these to some default value We would have to do it like this and You know I don’t see anything wrong with us necessarily, but this doesn’t really play well with our C++11 in class initializers, and we wanted to be able to do something like this and now we can we can specify the default member initializers for width fields and say that we want these values to be equal to 0 and effectively the compiler is going to synthesize a constructor for us that does what we want it to do and Now we can see the new warnings that we’re going to get with our clang in C++ to a mode Which we have this new warning that is warning this thing is not compatible c++98 c++11, c++14, c++17 and We can’t indeed see that if we take it back to C++17 standards, then we’re going to get this Bit field is a C++ 2a extension. It is still allowing us to do it so in this case This is the kind of thing that you want to make sure like you’re pedantic warnings are enabled for a so you’re not accidentally using features that are outside of The C++ specific standards that you’ve got now obviously we’re getting these warnings because of -WEverything anyhow and We probably would even without pedantic with this particular example There you have it so clang is good about warning about this in any case but just be sure to take advantage of your warnings and This is the first feature that we’re able to demonstrate on C++ weekly for C++ 20 or 2a as it is currently being called by your compiler vendors Be sure to subscribe follow me on Twitter and check out any of the links below

7 thoughts on “C++ Weekly – Ep 99 – C++ 20’s Default Bit-field Member Initializers

  1. Is Unified Call Syntax a feature that may be considered for C++20? I've seen some papers about it, and the ability to merge the 2 calling convention for member functions and functions taking a first object argument seems really necessary with the incoming Concepts TS!

  2. I wonder why have the commission decided not to include this in C++11 when in-class default values were introduced? Any thoughts?

  3. You can add ___atribute___ ((packed)); after the closing brace of the struct definition to prevent the compiler from padding the bitfield. This is often a bad idea because it will lead to less efficient code (there are good reasons why data is padded), but it is helpful in cases where you need precise control over the memory layout of a struct, for example so you can send it across a wire as-is.

  4. what happens when you change the fields from int i, int j to unsigned char i : 3, and unsigned char j : 5. The size of the returned structure goes to 1.

Leave a Reply

Your email address will not be published. Required fields are marked *