C++ 编译期确定的固定字符串集合常用存储方案有哪些？

常用的无动态内存、易维护的实现方案，按C++版本适配： #

1. 元素数量较少（20个以内）：优先用std::string_view编译期数组+线性遍历 #

适配C++17及以上版本，实现最简单，性能比哈希表更高，完全没有动态分配，不会抛异常：

#include <string_view>
#include <initializer_list>

// 新增运算符直接往列表里加即可，不需要修改判断逻辑
constexpr std::initializer_list<std::string_view> supported_operators = {
    "==", "!=", ">", "<", ">=", "<="
};

bool is_supported_op(std::string_view token) {
    for (auto op : supported_operators) {
        if (op == token) return true;
    }
    return false;
}

如果是C++11/14版本，把std::string_view换成const char*，字符串比较用strcmp即可。

2. 元素数量较多：编译期排序+二分查找 #

适配C++20及以上版本，时间复杂度O(logn)，适合几十到上百个元素的场景：

#include <array>
#include <string_view>
#include <algorithm>

// 按字典序预排好，或者用constexpr函数在编译期自动排序
constexpr std::array<std::string_view, 6> relational_operators = {
    "!=", "<", "<=", "==", ">", ">="
};

bool is_relational(std::string_view token) {
    return std::binary_search(relational_operators.begin(), relational_operators.end(), token);
}

新增元素只要往数组里加，保持字典序即可，不需要修改判断逻辑。

3. 极致性能需求：编译期完美哈希 #

如果元素上百个，追求零开销匹配，可以用gperf工具生成编译期完美哈希表，匹配时间是O(1)，完全没有运行时开销，只需要修改gperf的输入配置即可新增元素。

为什么不推荐用std::unordered_set #

你当前的实现确实存在不必要的风险：std::unordered_set初始化时需要动态分配哈希表内存，存储std::string还会为每个字符串单独分配堆内存，有抛出std::bad_alloc的可能。而且对于编译期已知的小集合来说，哈希计算、哈希表查找的开销远高于线性遍历或二分，性能反而更差。

内容的提问来源于stack exchange，提问作者senloa