From: Ivan Matek (libbooze_at_[hidden])
Date: 2025-06-12 08:53:45
On Thu, Jun 12, 2025 at 10:24 AM Alexander Grund via Boost <
boost_at_[hidden]> wrote:
> Compares the 2 approaches and I very much like the enum approach which
> does not pollute the global scope with constants that should be scoped
> too but isn't possibly with the strong type.
> See:
>
> > auto configuration = kUseSimd | kUsePrefetching;
> >
> > auto config = ConfigEnum::UseSimd | ConfigEnum::UsePrefetching;
>
As I said before you can limit the scope by introducting a namespace, i.e.
namespace ConfigEnum {
All this is stylistic obviously, but I do not like that you are creating
enum combination that does not represent any value from enum set.
Now we both know in C++ everything is allowed :) and then some more, so you
can freely bitwise or enums...
BTW Interesting proposal from 9 years ago:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0375r0.html
I am mostly talking about conceptual meaning of enum: set<int> is not int.
Again to be clear I am not arguing with you, just saying why I prefer one
style. And to keep our toy example from exploding into a full prototype I
will just briefly recap what would I prefer to see in "full" solution
1. difference between flag, and flag combination
2. wrap atomic operations so users can operate on ConfigFlag, and
ConfigFlagCombination(or AtomicConfigFlagCombination if we feel using
atomic for each use case is too slow), while underlying logic is as if they
are operating on atomic<uint32_t>
1. is :
struct ConfigFlag {
uint32_t val;
};
// combination of 0 or more ConfigFlag
struct ConfigFlagCombination {
uint32_t val;
};
ConfigFlagSet operator | (ConfigFlag a, ConfigFlag b) {
return {a.val|b.val};
}
2. is: TODO :)
I believe this may be considered over engineering a simple problem, but in
large codebase where this pattern is used a lot might be worth it.