On 4/13/26 22:31, Robert Baumgartner via Std-Proposals wrote:
> I want to solve the following problem: I have an enum type, potentially a large one like a set of actions. A subset of that enum type satisfies certain conditions that I want to check at runtime. That would look like this
>
> if(someSet.contains(x)) {
> // do something
> }
>
> std::unordered_set<T> does this job efficiently, but has to be initialized during run-time. This is suboptimal whenever the values are known at compile time, especially in ultra-low latency environments, where the run-time initialization adds overhead that can be avoided.

Well, if the values are known at compile-time, I'd expect that you initialize the
unordered_set during process startup (as global initialization), so this overhead
doesn't appear during execution.

The run-time overhead you do have with std::unordered_set is the pointer-based data
structure, which is likely to cause quite a bit of cache footprint.

> The currently best compile solution that I am aware of is using a std::array like
>
> inline static constexpr array mySet{a, b, c, …};
>
> , which is O(log(n)) run-time at best for a lookup operation, but requires manual sorting for optimal performance and lacks the semantics of a set.

Feel free to define a constexpr or consteval helper function that
initializes the array appropriately, and ensures duplicates are
flagged or ignored.

> A combined std::static_unordered_set<T, N> merges both solutions in one, combining run-time efficiency with compile-time initialization.

What would the main data structure of this beast look like?
Similar to std::unordered_set? Then you're already sub-optimal.
 
> I'm aware of third-party solutions like |frozen|, and of |std::flat_map| (C++23) and |constexpr std::map| (C++26),

What doesn't work, for your use-case, using each of these approaches?

> which suggest the committee has appetite for this direction. I'd welcome pointers to any prior proposals I may have missed, and feedback on whether this is worth developing into a formal paper.

What's the size (number of enumerators) of your enum?
A std::bitset might work well for that case, if all bits
fit in a few cache lines.

If you use a hash table, you likely want power-of-2 sizing
(for efficient slot number computation). Ideally, you want
to precompute the optimal size for the given (constant) values
such that no collisions appear, and maybe fiddle with the hash
function a bit to achieve that. (And consider that no-collisions
might not be achievable in the general case.)

For simple "int"s (e.g. enum values), CRC32 works fine as a hash
function for me, and comes with a cost of very few clock cycles
if you use the compiler intrinsic.

Jens