When faced with weird results coming from everyday tools, it can be very tempting to discard those results in disbelief by calling it a bug. The fact that those weird results are rare occurrences, that they may be not reproducible in the developer’s environment, and most importantly, that the developer cannot understand how to explain them, are strong incentives to discard those reports. And yet, it is very important to fight the urge to mistrust your tools because in most occurrences, they are absolutely right.
Back in 2016, I wrote a blog post about enum class bitfields that was influenced by Anthony William’s blog post about the very same topic: how to painlessly enable bitmask operators with the enum class feature that was introduced with C++11 for increased type safety and convenience. After using this in production code for a while, the amount of programming errors related to implicit conversions has diminished as usage has increased and legacy code has slowly converted. Yet, even by using this tool, I managed to write buggy code such as the following.
1
2
auto someMask = f();
if (someMask == myEnum::someEnumerator)
I wrote an article two years ago about a peculiar usage of Boost.ICL with a DomainType that changes (dynamically) at runtime. That domain could be described as the elements of a container ordered according to a strict weak relationship. The implementation I offered worked, but it suffered a few weaknesses. The present article will go over the various weaknesses and offer a new implementation that addresses those issues. If you want to skim over the previous implementation, you can find it on Github over here.