c++ - 在编译时填充 std::array 和 const_cast 可能的未定义行为

Question

已知std::array::operator[]由于 C++14 是 constexpr，请参见下面的声明:

constexpr const_reference operator[]( size_type pos ) const; 

但是，它也是 const 限定的。如果您想使用 std::array 的下标运算符以便在编译时为数组赋值，这会产生影响。例如考虑以下用户文字:

template<typename T, int N>
struct FooLiteral {
  std::array<T, N> arr;
  constexpr FooLiteral() : arr {} { for(int i(0); i < N; ++i) arr[i] = T{42 + i}; }
};

如果您尝试声明类型为 FooLiteral 的 constexpr 变量，上述代码将无法编译。这是因为重载解析规则将数组下标运算符的非 const 限定、非 constexpr 重载限定为更好的匹配。因此，编译器会提示调用非 constexpr 函数。

Live Demo

我无法弄清楚委员会将此重载声明为符合 C++14 条件的 const 的原因是什么，但是似乎人们注意到了其中的含义，并且还有一个提案p0107R0在即将发布的 C++17 中修复此问题。

对于 C++14，我很自然地要克服这个问题，以某种方式破解表达式，以唤起正确的下标运算符。我所做的是:

template<typename T, int N>
struct FooLiteral {
  std::array<T, N> arr;
  constexpr FooLiteral() : arr {} { 
    for(int i(0); i < N; ++i) {
      const_cast<T&>(static_cast<const std::array<T, N>&>(arr)[i]) = T{42 + i};
    }
  }
};

Live Demo

那是我将数组转换为 const 引用以引发正确的下标运算符重载，然后我将 const_cast 重载下标运算符的返回对象转换为 T& 为了移除它的 const-ness 并能够分配给它。

这很好用，但我知道 const_cast 应该谨慎使用，坦率地说，我对这个 hack 是否会导致未定义的行为有重新考虑。

直觉上，我不认为有问题，因为这个 const_cast 发生在编译时初始化，因此我想不出在这种状态下可能出现的含义。

但是是这样吗，还是我错了，这将 UB 引入了程序？

问:

有人可以证明这是否是 UB 吗？

Answer 1

据我所知，这不是未定义的行为。提案that added constexpr operator[] 发生在 changes that removed the implicit const from constexpr member functions 之前.所以看起来他们只是在 constexpr 上添加，而没有考虑是否需要保留 const。

我们可以看到 Relaxing constraints on constexpr functions 的早期版本它说了以下关于在常量表达式中改变文字的内容:

Objects created within a constant expression can be modified within the evalution of that constant expression (including the evaluation of any constexpr function calls it makes), until the evaluation of that constant expression ends, or the lifetime of the object ends, whichever happens sooner. They cannot be modified by later constant expression evaluations. [...]

This approach allows arbitrary variable mutations within an evaluation, while still preserving the essential property that constant expression evaluation is independent of the mutable global state of the program. Thus a constant expression evaluates to the same value no matter when it is evaluated, excepting when the value is unspecified (for instance, floating-point calculations can give different results and, with these changes, differing orders of evaluation can also give different results).

我们可以看到我引用的早期提案指出了 const_cast hack 并且它说:

In C++11, constexpr member functions are implicitly const. This creates problems for literal class types which desire to be usable both within constant expressions and outside them:

[...]

Several alternatives have been suggested to resolve this problem:

• Accept the status quo, and require users to work around this minor embarrassment with const_cast.