这应该是 constexpr 还是不？

Question

考虑这个代码片段（Godbolt）：

#include <cstdio>
#include <string>
#include <string_view>

struct Option
{
    std::string_view name;

    constexpr Option( std::string_view const n ) noexcept : name{n} {}
};

template< std::size_t N >
class TransformedOption : public Option
{
public:
    constexpr TransformedOption( std::string_view const nameStr ) :
        Option{ { nameStorage_, N - 1 } }
    {
        for ( auto i = 0U; i < N; ++i )
        {
            if ( nameStr[ i ] == '_' ) { nameStorage_[ i ] = '-'; }
            else                       { nameStorage_[ i ] = nameStr[ i ]; }
        }
    }
    private:
        char nameStorage_[ N ] = {};
};

template< std::size_t N >
constexpr TransformedOption< N > make( char const (&nameStr)[ N ] ) noexcept
{
    return TransformedOption< N  >{ nameStr };
}

int main()
{
    /*constexpr*/ auto t = make( "abcd_efgh_ijkl_mnop_peqst" );
    std::printf( "%s\n", t.name.data() );
    return 0;
}

基本上，我想通过将每个替换_为-并确保最终二进制文件仅包含转换后的字符串（而不是原始字符串）来执行编译时字符串转换。

我试过 Clang 10.0.1、GCC 10.2 和 MSVC 19.24（见上面的 Godbolt 链接）。奇怪的东西如下：

• 如果在 中constexpr被注释掉main，则 MSVC 生成不正确的代码（即字符串的运行时转换），但 GCC 和 clang 生成正确的代码（即转换后的字符串常量被嵌入到程序集中）
• 如果constexpr没有在 中注释掉main，那么 MSVC 会生成正确的代码（即转换后的字符串常量被嵌入到程序集中），但是 GCC 和 clang 都无法编译代码，说明它t不是由常量表达式初始化的（参见Godbolt）。最奇怪的是 GCC 错误消息，它在错误中输出转换后的字符串，并声明它不是一个常量表达式。

那么，根据 C++ 标准，哪个编译器是正确的？我应该向谁报告错误？给 GCC 和 Clang 的人还是给微软？

Answer 1

constexpr当t也声明为静态时，该声明适用于所有编译器。

constexpr static auto t = make( "abcd_efgh_ijkl_mnop_peqst" );

原因是string_view. 它是一种引用类型，用于引用正在初始化的对象。因此，以一种或另一种方式，您正在初始化一个contexpr指针。现在，constexpr指针（未初始化为空指针）只能使用具有静态存储持续时间的对象的地址进行初始化。

[expr.const]（强调我的）

11常量表达式要么是泛左值核心常量表达式，它指的是作为常量表达式（如下定义）的允许结果的实体，要么是其值满足以下约束的纯右值核心常量表达式：

• 如果值是类类型的对象，则每个引用类型的非静态数据成员都引用一个实体，该实体是常量表达式的允许结果，
• 如果值是指针类型，则它包含具有静态存储持续时间的对象的地址、超过此类对象末尾的地址 ([expr.add])、非立即函数的地址或空指针价值，
• 如果该值是指向成员函数的指针类型，则它不指定立即函数，并且
• 如果值是类或数组类型的对象，则每个子对象都满足该值的这些约束。

如果实体是具有静态存储持续时间的对象，该对象不是临时对象，或者是值满足上述约束的临时对象，或者是非立即函数，则该实体是常量表达式的允许结果。

当您将对象声明为自动存储期时， 中的指针string_view未使用静态对象的地址进行初始化。因此 GCC 和 Clang 抱怨是理所当然的。

自我引用使这变得有趣和棘手。