在构造/析构函数中安全使用std::is_constant_evaluated的可行性探讨

我们想要实现一个可通过std::string_view构造的C风格字符串包装类，设计逻辑如下：

• 运行时：将字符数组复制到包装类内部
• 编译时：直接复制字符数组的指针（假设原字符串是字面量，仅复制指针是否安全？）

析构逻辑对应：

• 运行时：释放内部存储的字符数组
• 编译时：不执行释放操作（仅将指针置为nullptr）

计划用std::is_constant_evaluated()来区分编译时和运行时逻辑，这种实现是否安全？存在哪些可能引发问题的边缘场景？

示例实现 #

class String {
public:
    constexpr String() noexcept = default;

    explicit constexpr String(std::string_view str) {
        copy(str.data(), str.size());
    }

    constexpr String(const String& other) {
        copy(other.data(), other.size());
    }

    constexpr String(String&& other) noexcept
        : data_(std::exchange(other.data_, nullptr)),
          size_(std::exchange(other.size_, 0)) {}

    constexpr ~String() {
        clear();
    }

    constexpr String& operator=(const String& other) {
        clear();
        copy(other.data(), other.size());
        return *this;
    }

    constexpr String& operator=(String&& other) noexcept {
        data_ = std::exchange(other.data_, nullptr);
        size_ = std::exchange(other.size_, 0);
        return *this;
    }

    // ...

    constexpr const char* data() const noexcept { return data_; }
    constexpr size_t size() const noexcept { return size_; }

private:
    constexpr void clear() {
        size_ = 0;
        if (std::is_constant_evaluated()) {
            data_ = nullptr;
        } else {
            delete[] data_;
        }
    }

    constexpr void copy(const char* data, size_t size) {
        if (std::is_constant_evaluated()) {
            data_ = const_cast<char*>(data);
        } else {
            data_ = new char[size];
            std::copy(data, data + size, data_);
        }
        size_ = size;
    }

    char* data_{nullptr};
    size_t size_{0};
};

一、核心安全性问题 #

1. 编译时指针的生命周期风险 #

std::is_constant_evaluated()只能判断当前代码是否处于常量求值上下文，无法保证传入的std::string_view指向的是静态生命周期的字面量：

• 若编译时构造时，传入的std::string_view指向栈上临时数组（哪怕是在常量表达式中创建的），编译时复制的指针会在常量求值结束后变成悬垂指针。
• 例：constexpr String s(std::string_view{std::array<char,5>{'a','b','c','d','\0'}.data(),4});，std::array临时对象销毁后，s.data()会指向已释放的内存。

2. const_cast引发的未定义行为 #

编译时逻辑中用const_cast<char*>(data)将const char*转为char*，但如果原指针指向只读内存（如字符串字面量），后续修改data_指向的内容会触发未定义行为。而包装类的data_是char*类型，没有const限定，极易被误用。

二、边缘场景隐患 #

1. 同一对象的编译/运行时行为分裂 #

若String对象在常量表达式中构造，后续在运行时被修改或赋值，会触发逻辑冲突：

• 例：constexpr String s("hello");，此时s.data()指向字符串字面量；运行时调用s = String("world");，赋值操作会先执行clear()，此时std::is_constant_evaluated()返回false，会尝试delete[] data_——但data_指向只读的字符串字面量，delete[]只读内存属于未定义行为。

2. 拷贝构造的逻辑漏洞 #

当拷贝编译时构造的String对象到运行时构造的对象时，运行时分支会正常分配内存并复制内容，这本身没问题；但反过来，若尝试在编译时拷贝运行时构造的对象（会触发编译错误，因为常量求值不允许new操作），一旦代码路径误触，会直接导致编译失败。

3. 移动语义的内存泄漏风险 #

移动构造函数直接交换data_指针，未区分编译时和运行时：

• 若将运行时构造的对象移动到编译时对象，编译时持有堆内存指针后，析构时std::is_constant_evaluated()返回true，只会将指针置为nullptr，不会释放堆内存，导致内存泄漏。

三、结论 #

这种实现不安全，核心问题在于std::is_constant_evaluated()无法准确判断传入字符串的生命周期属性，且编译时与运行时的行为分裂极易引发未定义行为。

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