C++如何实现签名一致、编译期求值的字符串空操作策略类

核心问题 #

实现可互相替换的字符串处理策略类时，恒等（空操作）策略存在两个典型问题：

• 无法在和其他策略保持统一调用接口（不强制要求传入右值）的前提下，利用移动语义避免不必要的字符串拷贝
• 旧标准下std::string不是字面量类型，无法给空操作函数加constexpr实现编译期求值

标准实现思路 #

这个场景的通用解决方案是统一所有策略的edit接口为按值传递std::string参数，这是C++中处理“可能返回修改后的副本、可能原样返回”这类值语义函数的公认最佳实践：

• 接口完全一致：所有策略的函数签名完全相同，符合策略模式的可替换要求，调用方不需要为不同策略写特殊的传参逻辑
• 开销自动最优：左值传入时，仅发生一次必要的拷贝（需要保留原字符串的场景下拷贝不可避免）；右值传入时，编译器会自动触发移动构造，全程没有额外拷贝，比const std::string&传参+内部拷贝的写法在右值场景下性能更高
• 语义清晰：按值传参明确表示函数取得参数的所有权，不会修改调用方持有的原变量，符合字符串处理的通用语义

关于constexpr的问题：C20及以上标准已经支持constexpr std::string，直接给函数加constexpr修饰即可实现编译期求值；C17及更早版本不需要强行加constexpr，恒等逻辑足够简单，开O2及以上优化级别时编译器会100%内联消掉函数调用，甚至直接完成编译期求值，不会有运行时开销。

修正后完整代码 #

#include <string>
#include <regex>
#include <cassert>

/// @brief 恒等策略：不对字符串做任何修改
struct identity
{
    // C++20及以上可加constexpr修饰实现编译期求值：
    // static constexpr std::string edit(std::string s)
    static std::string edit(std::string s)
    {
        // 返回局部形参时编译器自动触发移动/RVO，无需手动加std::move
        return s;
    }
};

template<unsigned int N>
struct remove_comments_of_depth
{};

/// @brief 注释深度0：不删除任何内容，直接复用恒等策略
template<> struct remove_comments_of_depth<0> : identity
{};

/// @brief 注释深度1：删除方括号包裹的所有注释内容
/// @note 假设输入格式合法，不存在嵌套方括号或未闭合括号
template<> struct remove_comments_of_depth<1>
{
    // 和恒等策略保持完全一致的接口签名
    static std::string edit(std::string s)
    {
        // 正则加static避免每次调用都重新编译，大幅提升性能
        const static std::regex comment_regex(R"(\[[^()]*\])");
        return std::regex_replace(s, comment_regex, "");
    }
};

int main(int argc, char *argv[])
{
    using namespace std::string_literals;
    std::string s = "my_string[this is a comment]";
    auto copy = s;
    assert(remove_comments_of_depth<1>::edit(s) == "my_string");
    // 不需要手动调用std::move，接口完全兼容左值传入
    assert(remove_comments_of_depth<0>::edit(copy) == s);
    // 右值传入时自动触发移动，无额外拷贝开销
    assert(remove_comments_of_depth<0>::edit("test"s) == "test"s);
    return 0;
}

额外说明 #

• 如果你需要在恒等场景下完全避免拷贝，也可以主动给调用传入右值（比如std::move(copy)），这个写法对所有策略都生效，不需要针对恒等策略做特殊处理
• 注意不要在返回局部形参时手动加std::move，这会抑制编译器的返回值优化（RVO），反而会增加不必要的移动开销

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