> Are you looking for

> serge-sans-paille/frozen: a header-only, constexpr alternative to gperf
for C++14 users <https://github.com/serge-sans-paille/frozen>

> ?


Thank you - frozen is exactly the kind of third-party solution I mentioned.
The question is whether something equivalent belongs in the standard
library
with a guaranteed interface and without an external dependency.

Am Mo., 13. Apr. 2026 um 23:10 Uhr schrieb Zhihao Yuan <zy_at_[hidden]>:

> Are you looking for
>
> serge-sans-paille/frozen: a header-only, constexpr alternative to gperf
> for C++14 users <https://github.com/serge-sans-paille/frozen>
>
> ?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
> On Monday, April 13th, 2026 at 1:32 PM, Robert Baumgartner via
> Std-Proposals <std-proposals_at_[hidden]> 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.
>
> 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.
>
> A combined std::static_unordered_set<T, N> merges both solutions in one,
> combining run-time efficiency with compile-time initialization.
>
> I'm aware of third-party solutions like frozen, and of std::flat_map (C++23)
> and constexpr std::map (C++26), 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.
>
> Best regards,
>
> Robert Baumgartner
>
> My website: https://robba.github.io
>
>
>