Last time I wrote a class for\u00a0a bitfield and a macro that allowed us to automatically size the bitfield storage based on size of flag set and platform storage sizes. \u00a0And that’s great and all, but we only went from something like Bitflag<unsigned int> m_flags to something like Bitflag<BITFLAG_SIZE(28)> m_flags. \u00a0It’s better from the perspective of what I was writing about in that last post, but you still have a hardcoded 28 sitting there, completely detached from the flag set it is trying to describe. \u00a0Wouldn’t it be great if you could feed your flag set directly into the BITFLAG_SIZE macro, and then changes to the flag set automatically change the macro, which changes the type? \u00a0Why, yes, yes it would.<\/p>\n
So, can we do it? \u00a0Absolutely! \u00a0But, before we get to that answer, we’re going to take a detour through enums.<\/p>\n
I love enums. \u00a0Especially unscoped enums wrapped inside of their own namespaces. \u00a0I use them all the time. \u00a0Most of that usage is to describe entries in a statically sized array, along the lines of this:<\/p>\n
\r\nnamespace CommandListLayers\r\n{\r\n enum Layer\r\n {\r\n Read,\r\n Pivot,\r\n Write,\r\n NumberOf\r\n };\r\n}\r\n<\/pre>\nI have a system that uses an array of 3 command lists to move render data between the game thread and the render thread; the read layer, the write layer, and the pivot layer. \u00a0I can initialize\u00a0the array with CommandListLayers::NumberOf, and any code I write can deal with each of the layers via the associated enumerator. \u00a0It’s clean and it’s easy. \u00a0I really like the NumberOf trick, but it’s also kind of tedious to always insert it at the end. \u00a0Or, being the stupid human that I am, maybe I forget to do it. \u00a0Who knows! \u00a0So, one day I came up with this dumb macro.<\/p>\n
\r\n#define ARRAY_ENUM_BUILDER(name1, name2, ...) \\\r\n namespace name1 { \\\r\n enum name2 { \\\r\n __VA_ARGS__, \\\r\n NumberOf \\\r\n }; \\\r\n }\r\n<\/pre>\nAnd that allows the enum declaration to look like this.<\/p>\n
\r\nARRAY_ENUM_BUILDER(\r\n CommandListLayers, Layer, \r\n Read,\r\n Pivot,\r\n Write\r\n)\r\n<\/pre>\nSo, I declared the namespace and enum name, all enumerator entries, and the NumberOf gets tacked onto the end with the correct value. \u00a0Great! \u00a0So, what does this have to do with my Bitflag class and the BITFLAG_SIZE macro? \u00a0Well, given the enum stuff I was already doing in my code, the next logical step was to do something like this.<\/p>\n
\r\nnamespace ProcessToggleFlags\r\n{\r\n enum Flags\r\n {\r\n Lighting = (1 << 0),\r\n DepthOfField = (1 << 1),\r\n Wireframe = (1 << 2),\r\n DebugLines = (1 << 3),\r\n DebugText = (1 << 4),\r\n NumberOf = 5\r\n };\r\n}\r\n<\/pre>\nSo, this is a little less great. \u00a0I have to manually assign a value to NumberOf since it would otherwise take the next integral value beyond (1 << 4), which isn’t 5, which is what I would want NumberOf to be in this case. \u00a0So, the macro as it exists for building enums that describe arrays isn’t going to cut it. \u00a0That’s where this template code comes in!<\/p>\n
\r\nnamespace enum_helpers\r\n{\r\n template <unsigned long long T>\r\n struct enum_size\r\n {\r\n static const unsigned long long count = enum_size<(T >> 1)>::count + 1;\r\n };\r\n\r\n template <>\r\n struct enum_size<0>\r\n {\r\n static const unsigned long long count = 0;\r\n };\r\n}\r\n<\/pre>\nUsing that template code, I can now create a new macro specifically to build enums for bitfields. \u00a0And that macro looks like this.<\/p>\n
\r\n#define BITFLAG_ENUM_BUILDER(name1, name2, ...) \\\r\n namespace name1 { \\\r\n enum name2 : unsigned long long { \\\r\n __VA_ARGS__, \\\r\n Last, \\\r\n NumberOf = enum_helpers::enum_size<Last - 1>::count \\\r\n }; \\\r\n }\r\n<\/pre>\nWhich allows my enum to becomes this.<\/p>\n
\r\nBITFLAG_ENUM_BUILDER(\r\n ProcessToggleFlags, Flags, \r\n Lighting = (1 << 0),\r\n DepthOfField = (1 << 1),\r\n Wireframe = (1 << 2),\r\n DebugLines = (1 << 3),\r\n DebugText = (1 << 4)\r\n)\r\n<\/pre>\nIt works more or less the same as the ARRAY_ENUM_BUILDER macro, but it tacks on a Last entry with the sole purpose of being the parameter into the enum_size template, giving us the correct value for NumberOf when dealing with bit flags. \u00a0So, that’s great, right? \u00a0Now we can move from Bitflag<BITFLAG_SIZE(28)> m_flags to Bitflag<BITFLAG_SIZE(ProcessToggleFlags::NumberOf)> m_flags. \u00a0And that’s definitely better. \u00a0More or less where I want to be with this.<\/p>\n
However, there are still some things I’d like to improve. \u00a0It would be nice if I could get the element count from __VA_ARGS__ or iterate over the contents. \u00a0Then I could generate the type of the enum, insert the shift values, and any necessary suffixes on the 1’s from inside the macro. \u00a0And it isn’t like it’s completely undoable, but it moves into the realm of really gross macro code. \u00a0Code I will probably end up writing for myself, but it’s not overly scaleable so I didn’t want to include it here.<\/p>\n
But, that’s it. \u00a0This template and 2 macros make my life a lot easier. \u00a0Hopefully it will do the same for someone else. \u00a0Here is the download link if you want all of the source: EnumHelpers.hpp<\/a>. \u00a0And if anyone has suggestions for improvements (especially for doing the things I mentioned in the previous paragraph!), I’d love to hear those.<\/p>\nUntil next time!<\/p>\n","protected":false},"excerpt":{"rendered":"
Last time I wrote a class for\u00a0a bitfield and a macro that allowed us to automatically size the bitfield storage based on size of flag set and platform storage sizes. \u00a0And that’s great and all, but we only went from something like Bitflag<unsigned int> m_flags to something like Bitflag<BITFLAG_SIZE(28)> m_flags. \u2026 Continue reading