問題タブ [constexpr]

私が理解しているように、constexprテンプレートメタプログラミングとは異なりチューリング完全ではないので、これらは同じではないと思います。では、問題は、テンプレートメタプログラミングをどの程度constexpr時代遅れにするのかということです。

私は持っています：

エラーが発生しています：

理由について何か考えはありますか？

C++11 を使用して、コンストラクターを使用して、以下のinitializer_listような再帰的に定義されたクラスをアセンブルすることは可能ですか?Fooconstexpr

Foo<3>次を使用して初期化できます。

代わりに Foo<3> a = {1,2,3} を使用するとよいでしょう。constexpr tail機能があれば、initializer_listうまくいくはずです。

私は次のようなconstexpr関数を持っています：

しかし、これをGCC 4.6.3でコンパイルすると、私に言われ続けます

エラー：「バー」は定数式に表示できません

私は次のようなことを試みました

ただし、constexprは関数の引数には使用できません。

バーが常にコンパイル時定数であることをコンパイラに伝える簡単な方法はありますか？

gccでコンパイルすると、エラーが発生します。

エラー：中括弧で囲まれた初期化子は、「{」トークンの前では許可されていません

これはconstexprの違法な使用ですか？

編集

3つの異なるバージョンのgccを試しましたが、最新の4.7.0でコンパイルされたため（ダウンロードしたばかりで、mingw-w64を使用しています）、修正されたバグのようです（バグへのリンクはでもいいです！）。

4.7.0 20120311（プレリリース）//わかりまし
た4.6.4 20120305（プレリリース）//エラー
4.7.0 20110829（実験的）//エラー

以前、引数が であるかどうかに基づく関数のオーバーロードconstexprについて質問しました。その質問に対する残念な答えを回避して、よりスマートなアサート関数を作成しようとしています。これは大まかに私がやろうとしていることです:

基本的に、コンパイル時にチェックできるのであれば、コンパイル時チェックは常に実行時チェックよりも優れているという考えです。ただし、インライン化や定数の折りたたみなどにより、コンパイル時のチェックが可能かどうかを常に知ることはできません。assert (condition)これは、コンパイルしてassert(false)コードが実行されるのを待っているだけで、エラーがあることに気付く前にそのパスを実行する場合があることを意味します。

したがって、(インライン化またはその他の最適化により) 条件が constexpr であるかどうかを確認する方法があれば、static_assert可能な場合は呼び出し、それ以外の場合は実行時のアサートにフォールバックできます。幸いなことに、gcc には組み込みのがあり、 が constexpr__builtin_constant_p (exp)の場合に true を返します。exp他のコンパイラにこの組み込み関数があるかどうかはわかりませんが、これで問題が解決することを期待していました。これは私が思いついたコードです：

は、のstatic_assert短絡動作に依存していorます。IS_CONSTEXPRが真の場合、使用static_assertでき、条件は!true or conditionであり、これは単に と同じconditionです。IS_CONSTEXPRが false の場合はstatic_assert使用できず、条件は!false or conditionであり、これは と同じでtrueあり、static_assertは無視されます。static_assertが constexpr ではないためにチェックできない場合は、最後の努力としてconditionランタイムをコードに追加します。assertただし、引数が であっても、関数の引数を astatic_assertで使用できないため、これは機能しません。constexpr

特に、gcc でコンパイルしようとすると、次のようになります。

g++ main.cpp -std=c++0x -O0

すべて問題なく、正常にコンパイルされます。最適化なしのインライン化はないため、IS_CONSTEXPRfalse であり、static_assert無視されるため、実行時assertステートメント (失敗) を取得するだけです。でも、

最適化をオンにしてstatic_assertトリガーを許可するとすぐに、 で関数引数を使用できないため、失敗しますstatic_assert。これを回避する方法はありますか (それが私自身の実装を意味する場合でもstatic_assert)? 私の C++ プロジェクトは、できるだけ早くエラーをキャッチするよりスマートな assert ステートメントから理論的にかなりの恩恵を受けることができると思います。

smart_assert関数のようなマクロを作成しても、一般的なケースでは問題が解決しないようです。この単純な例では明らかにcondition機能しますが、コール グラフの 2 レベル上の関数から発生した可能性があります (ただし、constexprインライン化により、コンパイラには認識されるようになります)。これは、関数パラメーターを使用する場合と同じ問題に遭遇します。でstatic_assert。

一定の整数値に初期化された constexpr ポインターを宣言しようとしていますが、clang は私の試みをすべて失敗させています。

試行 1:

試行 2:

試行 3:

私がやろうとしていることは、設計上許可されていませんか? もしそうなら、なぜですか？そうでない場合は、どうすればよいですか？

注: gcc はこれらすべてを受け入れます。

以下の定義を検討してください。

完全なエラーは

../main.cpp:16:3：エラー：静的アサーションの条件が一定ではありません

../main.cpp:16:3：エラー：'（（（const char *）（＆Test :: wrong_string））==（（const char *）（＆Test :: right_string）））'は定数式

これはコンパイラのバグだと思います。なぜなら、テンプレートパラメータとして渡すもの（または）に応じてconstexpr、内部の式の性質がstatic_assert変化することは意味がないからです。Test::right_stringTest::right_string

アドレスをテンプレートパラメータとして処理する場合、g++4.6に多少の欠陥があることはすでにわかっています。これは同じバグのインスタンスですか？

コンパイル時と実行時の両方で機能する文字列を実装する方法はありますか？

クラスをconstexprで構築するには、簡単なデストラクタが必要です。ただし、文字列を扱う場合、これは難しいことがわかります。文字列がconstexprでない場合は、メモリの割り当てを解除する必要があります。ただし、constexprの場合は、静的に割り当てられているため、削除しないでください。したがって、簡単なデストラクタが許可されます。

ただし、「ねえ、コンパイラ！私がconstexprなら、私を破壊する必要はありません！」と言うことはできません。またはそれは？

次のようになります。

私が到達できた最も近いものは、stringとconstexpr_stringの2つの別個のタイプ、constexpr_stringを返すユーザー定義のリテラル_string、およびconstexpr_stringからstringへのユーザー定義の暗黙の変換です。

const auto s = "asdf"_string;動作するが動作しないので、これはあまり良くありconst string s = "asdf"_string;ません。さらに、constexpr_stringへの参照/ポインタは変換されません。どちらの方法でも継承すると、直感的でない「落とし穴」が発生し、最初の問題は解決されません。

これは、コンパイラーがconstexprを破棄する必要がないことをプログラマーに信頼させる限り、可能であるように思われます。

誤解がある場合はお知らせください。

constexpr 関数 (C++ 2011) を使用して配列全体を初期化することは可能かどうか疑問に思います。ここに、私がやりたいことを説明する何かがあります:

配列を手動で埋めずに myVar を constexpr で初期化する方法はありますか? そして、それが存在する場合、与えられた例の構文は何ですか?

質問を少し正確にするために、1 回の関数呼び出しを使用して myVar のすべての値を埋める方法を探します。