On 22.03.2017 20:14, Richard Hodges via Boost wrote:
I agree that bitfields are not the way to go. They suffer from a number of deficiencies - not least that each bit is *not a separate object* so they are problematic i multithreaded environments. They also of course carry no type information.
However, I am struggling to see how the proposed class is any more useful than a std::tuple classes that support a bool conversion operator.
Can you demonstrate a use case where a tuple is inadequate?
std::tuple and proposed class typed_flags are completely different. Via std::tuple you can emulate typed bit storage like this class p1; // class p2; // incomplete types class p3; // template<typename T> struct bit { unsigned char value; }; std::tuple<bit<p1>, bit<p2>, bit<p3>> b1; assert( sizeof(b1) == 3 ); std::tuple can be parameterized only with *complete* types because it stores instances of specified types. Thus in this example the size of b1 is 3 bytes. We can't write std::tuple in this way std::tuple<p1, p2, p3> b2; typed_flags can be parameterized with *incomplete* types because types are used as tags for identifying positions of corresponding bits. typed_flags<p1, p2, p3> b3; assert( sizeof(b3) == 1 ); Actual bit values are stored in std::array<uint8_t, N> where N is calculated depending on the number of template parameters. So typed_flags is a templated frontend to the raw bit storage. When we test a certain flag (or bit) b3.test<p2>(); the type p2 is resolved to the item in the backing array and offset inside the item. typed_flags API is similar to std::bitset. I can't post verbose examples here. For better understanding, please, take a look at my repo https://github.com/compmaniak/typed_flags