6

Ubuntu 13.04でGCC 4.7.3標準ライブラリヘッダーファイルを使用してclang 3.3を使用して、かなり大きなコード本体をコンパイルしようとしました。これは、1 つの問題を除いてすべてうまくいきました。このコードは、このマシンの標準の 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; }

これにより、次のように実際のメンバー関数が const ではないというエラーが clang で生成されます。

/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 は間違っています。

4

1 に答える 1