clang 3.3和GCC 4.7 const v的constexpr

Question

我刚刚尝试使用clang 3.3和Ubuntu 13.04上的GCC 4.7.3标准库头文件编译相当大的代码.除了一个问题外,一切顺利.这段代码已经在这台机器上编译了标准的Ubuntu clang 3.2软件包,所以我假设这是clang 3.3编译器的一些变化.与使用复杂标头的const和constexpr相关的问题.特别是复杂类型具有以下代码块

#ifdef __GXX_EXPERIMENTAL_CXX0X__
      // _GLIBCXX_RESOLVE_LIB_DEFECTS
      // DR 387. std::complex over-encapsulated.
      constexpr double
      real() { return __real__ _M_value; }

      constexpr double
      imag() { return __imag__ _M_value; }
#else
      double&
      real() { return __real__ _M_value; }

      const double&
      real() const { return __real__ _M_value; }

      double&
      imag() { return __imag__ _M_value; }

      const double&
      imag() const { return __imag__ _M_value; }
#endif

在我的编译中,我输入第一个代码块,因此编译器可以看到

constexpr double real() { return __real__ _M_value; }

这导致clang产生错误,实际成员函数不是const,具有以下内容

/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/complex:1212:7: 
note: candidate function not viable: 'this' argument has type 'const complex<double>',
      but method is not marked const

      real() { return __real__ _M_value; }

我已经阅读了以下帖子`constexpr`和`const`之间的区别以及一些其他类似的文档,但是如果这是GCC头问题或者clang编译器问题,我仍然不太清楚.我的感觉是标记为constexpr的成员函数应该被编译器视为const,在这种情况下clang是错误的.

Answer 1

根据clang 的状态页面,部分实现了对constexpr功能的N3652放宽要求.本文发生了很大的变化.以下段落已被删除.

非静态成员函数的constexpr说明符不是构造函数,它声明成员函数是const(9.3.1).

此更改意味着无法再在const对象上调用您的函数.另请参阅修复constexpr成员函数而不使用const,这是修复库中这些区域的提议.