エラーメッセージはかなり誤解を招くものです。動作は、確かにC++標準に則ったものであるが、いずれにせよ不便です。GCCは、当該コードを許します。
話題
About: C++
About: Visual C++
この記事の目次
- 開始コンテキスト
- ターゲットコンテキスト
- オリエンテーション
- 本体
- 1: 「C2131: expression did not evaluate to a constant」エラーに遭遇する
- 2: 原因
- 3: 解決策
開始コンテキスト
- 読者は、C++の基本的知識を持っている。
ターゲットコンテキスト
- 読者は、「C2131: expression did not evaluate to a constant」エラーメッセージの真の意味およびその問題を解決する方法を知る。
オリエンテーション
Visual C++の奇癖について、他にいくつか記事（「unable to match function definition to an existing declaration」エラー、DLLからシンボル群をエクスポートする、コンストラクタテンプレートを明示的にインスタンス化する、'std::codecvt<char16_t,char,struct _Mbstatet>'未解決エラー）があります。
本体
ト書きHypothesizer 7は、独白する。
1: 「C2131: expression did not evaluate to a constant」エラーに遭遇する
Hypothesizer 7
以下のコードは、Visual C++ 2017で、コンパイルエラー、「C2131: expression did not evaluate to a constant」を起こす、GCCでは問題ないのであるが。
@C++ ソースコード
void test2 (int const & a_arrayLength) {int l_array [a_arrayLength];}
2: 原因
Hypothesizer 7
そのエラーメッセージは、かなり誤解を招くものだ: 「did not evaluate to a constant」？それ、コンスタントですよね？
実のところ、問題は、C++の意味においてコンスタントでないことではなく、コンパイル時決定されないことである。 . . . なぜ、我々は用語体系をもっと正さないのか？C++は、用語体系がどうもだらしなさすぎる（「lvalue」、「rvalue」、「ムーブセマンティクス」、「xvalue」、「prvalue」、「glvalue」、「テンプレートインスタンス化」、等）。
スタック配列の長さがコンパイル時決定されなければならないという要求は、実際には、C++標準に則ったものであるのだが、不便である、いずれにせよ。
GCCはそのような要求を必要としないという事実を鑑みた上で、我々は本当にそのような要求を必要としているのだろうか？ . . . パフォーマンスのためだと言う人がもしもいるのであれば、私は納得しない: あらゆるスタック配列の長さがコンパイル時決定されるべきでないとは私は言っていない; なぜ、プログラマーの裁量に基づいて選択が許されるべきでないのかといぶかっているだけだ。コンパイル時決定されない長さの配列を許したからといって、コンパイル時決定される長さの配列が遅くならなければならないということはないのではありませんか？
3: 解決策
Hypothesizer 7
私が知る限りの唯一の解決策は、ヒープ配列を使用することだが、それを適切なタイミングで手動にて廃棄することが要求される。
