{"id":1836,"date":"2026-07-18T09:34:42","date_gmt":"2026-07-18T15:34:42","guid":{"rendered":"https:\/\/www.elbeno.com\/blog\/?p=1836"},"modified":"2026-07-18T19:41:13","modified_gmt":"2026-07-19T01:41:13","slug":"a-better-bitset-for-enum-flags","status":"publish","type":"post","link":"https:\/\/www.elbeno.com\/blog\/?p=1836","title":{"rendered":"A better bitset for enum flags"},"content":{"rendered":"\n

TL;DR: using enum<\/code> for bitflags is poor, but it’s what we’re likely to end up with.<\/p>\n\n\n\n

Many electrons have been spent expounding enumeration bitflag types (and not just in C++). As a tech community across multiple languages, we seem to be all in on the idea that the right way for this to look is something like:<\/p>\n\n\n\n

\/\/ I somehow opt in for bitwise operations on this type\nenum struct permissions {\n  NONE  = 0,\n  READ  = 1 << 0,\n  WRITE = 1 << 1,\n  EXEC  = 1 << 2\n};\n\n\/\/ then, I can use \"regular bitwise operators\"\nauto p = permissions::READ | permissions::WRITE;\nif ((p & permissions::READ) == permissions::READ) {\n  \/\/ ...\n}<\/code><\/pre>\n\n\n\n
Where in C++, opting in variously looks like adding a function declaration found by ADL, or adding a reflection annotation, or using a macro to provide operators, or\u2026<\/p>\n\n\n\n
We might well end up here in C++. With successive standards, we get new techniques which enable us to get there a little more easily, and C++26 reflection is the latest example of that. P4313<\/a> is a proposal for enum<\/code> flags in this style.<\/p>\n\n\n\n
I think it’s a workable approach (i.e. we will make<\/em> it work), but ultimately it seems to me that it’s the wrong direction. I think using a bitset is a much better solution. Unfortunately, std::bitset<\/code> can’t get us there, which is why we may end up with the enum<\/code> bitflags.<\/p>\n\n\n\n
The pros of enum<\/code> bitflags are usually given as:<\/p>\n\n\n\n
    \n
  1. Type safety (at least when using scoped enumerations). There is no implicit conversion between values of different types. We can’t accidentally confuse permissions with some other value.<\/li>\n\n\n\n
  2. Ergonomics of use. Using these things looks like using plain old integers. (I note that P4313 says<\/a> “plain C-style int<\/code>“, notwithstanding clang-tidy’s bugprone-signed-bitwise<\/a> check.)<\/li>\n<\/ol>\n\n\n\n
    I think the downsides are:<\/p>\n\n\n\n
      \n
    1. Ergonomics of implementation. As I said, problems are lessened with each C++ standard. And this is something the culture of C++ library authorship discounts: who cares how difficult it is to implement under the hood? But it’s still going to be kind of annoying to apply bit operations to enumeration types you don’t own.<\/li>\n\n\n\n
    2. Aesthetics. I don’t want<\/em> using these things to look like using plain old integers, because using plain old integers is fraught with peril. Which leads to\u2026<\/li>\n\n\n\n
    3. Ergonomics of use. Bitwise operators famously have the “wrong” precedence in C and C++, for historical reasons. Yes, please use your compiler warnings. Ironically the expositional code used in P4313<\/a> exhibits this well-known operator precedence error (which I corrected above)!<\/li>\n\n\n\n
    4. (Perhaps most significantly…) Conflation of ideas. enum<\/code> bitflags are easy, but not simple<\/a>. They complect naming<\/em> bits (what we actually want) with representing<\/em> them. True, it’s not our fault; this is the legacy of C that multiple languages double down on at this point. But it’s also not right. We say “the type has members A<\/code> and B<\/code>” then we pretend that A|B<\/code> is also a member of the type. But that’s immediately subverting type safety: we have confused representation with naming.<\/li>\n<\/ol>\n\n\n\n
      So what’s the alternative? Well unfortunately, std::bitset<\/code> doesn’t cut it<\/em>, and in all probability can’t be made to cut it<\/em>. But a better bitset could<\/em>, and is totally implementable. Here’s what I’d like it to look like.<\/p>\n\n\n\n
      enum struct permissions {\n  READ, WRITE, EXEC,\n  MAX \/\/ here's the conventional opt-in\n};\n\n\/\/ bitset can take an enum, and preserve it (type safety)\nusing perms_t = bitset<permissions::MAX>;\n\n\/\/ how about a tag constructor?\nauto p = perms_t{place_bits, permissions::READ, permissions::WRITE};\nif (p[permissions::READ]) {\n  \/\/ ...\n}<\/code><\/pre>\n\n\n\n
      As far as I can see, this solves almost (I’m being conservative in saying almost) all the problems with the enumeration approach.<\/p>\n\n\n\n
        \n
      1. Type safety. I can’t assign a perms_t<\/code> here from some other bitset<\/code> or from an integral type. And this is true even for unscoped enum<\/code>s I find in 3rd party libraries.<\/li>\n\n\n\n
      2. Ergonomics of use. operator[]<\/code> isn’t going to have the precedence problems of the bitwise operators. Enumeration values don’t have to be pre-shifted, avoiding a source of potential error.<\/li>\n\n\n\n
      3. Correct separation of concerns. The enumeration type names<\/em> the bits. The bitset<\/code> represents<\/em> them. We aren’t pretending that READ|WRITE<\/code> is a member of permissions<\/code>.<\/li>\n<\/ol>\n\n\n\n
        It still ticks the other boxes too. Implementation is at least as easy as, if not easier than, the enum<\/code> approach.<\/p>\n\n\n\n
        I think the one remaining problem is around the ergonomics of taking a 3rd party codebase whose enum<\/code>(s) I don’t own, and treating the enum<\/code>s as bits. Fair criticism. I think we are always going to find that there are ways this can be annoying. With the enum<\/code> bitflags approach I would use an intrusive opt-in mechanism something like injecting ADL-found functions into a 3rd party namespace. With a bitset approach, it’s not intrusive, but I still need to provide a “max” value (or otherwise specify the number of bits in some other API shape variation not shown here).<\/p>\n\n\n\n
        Both of these techniques mean that I might have to change code when upstream code changes. I think on balance the bitset approach is a bit easier, especially considering that we can probably use reflection to discover a suitable “max” value. (Unless a 3rd party library deliberately hides the enum<\/code> values away, and in that case, what would we use to name the bits anyway?)<\/p>\n\n\n\n
        But you’re still thinking this isn’t as nice as it could be, and you’re right, because so far you’re imagining std::bitset<\/code> with just these extras. For nice usage, this bitset<\/code> needs a few more things.<\/p>\n\n\n\n
        If we’re using a bitset for representation, well actually<\/em> we want an easy way to specify and get access to the underlying thing (like enum<\/code> can deal with its underlying type). Because ultimately types are all just compile-time fluff that the runtime doesn’t care about: these things do<\/em> need to be plain integral stuff under the hood.<\/p>\n\n\n\n
        So something like this:<\/p>\n\n\n\n
        using B1 = bitset<8>;                \/\/ 8 bits, a std::uint8_t underneath\nusing B2 = bitset<8, std::uint32_t>; \/\/ 8 bits, a std::uint32_t\nusing B3 = bitset<64>;               \/\/ 64 bits, a std::uint64_t\nusing B4 = bitset<64, std::uint8_t>; \/\/ 64 bits, a std::array<std::uint8_t, 8>\n\nenum struct permissions { READ, WRITE, EXEC, MAX };\nusing B = bitset<permissions::MAX, std::uint32_t>;<\/code><\/pre>\n\n\n\n
        Because we want to be able to make these size\/speed tradeoffs appropriately across platforms from tiny microcontrollers to massive servers.<\/p>\n\n\n\n
        And because this thing is<\/em> just integral stuff that we want to write to some serialization format, we want an easy way to do that.<\/p>\n\n\n\n
        auto perms = get_permissions();                \/\/ a bitset over permissions\nauto serial_perms = perms.to<std::uint16_t>(); \/\/ a std::uint16_t for serialization<\/code><\/pre>\n\n\n\n
        We can of course add several other nice things to a bitset type, for other uses cases. (e.g. Why is it so hard, in a generic way, to construct a std::bitset<\/code> with all the bits set? How do I iterate over set bits? How do I find the lowest unset bit?) But all that’s a different story.<\/p>\n\n\n\n
        Well, that’s about it. I think this bitset approach is much better than the enum<\/code> flags approach. It’s better even after successive C++ versions iron out more and more of the annoying niceties of enum<\/code> flags implementation. But we’re going to end up with enum<\/code> flags, aren’t we? And I guess we’ll just make it work.<\/p>\n","protected":false},"excerpt":{"rendered":"
        TL;DR: using enum for bitflags is poor, but it’s what we’re likely to end up with. Many electrons have been spent expounding enumeration bitflag types (and not just in C++). As a tech community across multiple languages, we seem to be all in on the idea that the right way…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[],"class_list":["post-1836","post","type-post","status-publish","format-standard","hentry","category-cpp"],"_links":{"self":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1836"}],"version-history":[{"count":10,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1836\/revisions"}],"predecessor-version":[{"id":1856,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1836\/revisions\/1856"}],"wp:attachment":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}