問題タブ [static-assert]

static_assert の文字列を動的にカスタマイズして表示する方法はありますか?
つまり、次のようなものです。

static_assert関数内でどのように適切に実行しconstexprますか？例えば：

constexpr関数にはreturnステートメントのみが含まれている必要があるため、これは有効なC++11コードではありません。この標準に例外があるとは思いませんが、GCC4.7ではこのコードをコンパイルできません。

これは不自然な例だと思いますが、これを防ぐためにコンパイルチェックが必要です...

重複の可能性:
クラスが静的アサートと型特性を使用して 2 回派生するのを防ぐ方法はありますか?

私が防ぎたいのは、複数の C ベースのテンプレートが D で派生することです (つまり、派生する C のインスタンスは 1 つだけであるべきです)。これを解決する可能性のあるCまたはBの静的アサートを期待していました。

特定のポリシーまたはタイプでは機能しないいくつかのメソッドを持つ複雑なテンプレート クラスがあります。したがって、これらの型を (コンパイル時に型特性を使用して) 検出すると、ナイス メッセージと共に静的アサーションを起動します。

現在、手動でテンプレートをインスタンス化する作業も数多く行っています。部分的には、メソッドが構文チェックのためにコンパイラーに強制されるようにするためです。また、ライブラリ ユーザーのコンパイル時間も短縮されます。問題は、静的アサーションが常に起動されるため、問題のテンプレート クラスを手動でインスタンス化できないことです。

これに対する回避策はありますか?

編集:より明確にするために、ここに例を示します (この場合の明示的なインスタンス化は someFunc1() で失敗します:

EDIT2：これは別の例です。今回は、それをコンパイルして、私が何を意味するかを確認できます。まず、すぐにコンパイルします。コードがコンパイルされるはずです。次に[2] のコメントを外すと、静的アサーションが起動します。[2] をコメントアウトし、 [1]をコメント解除します。テンプレートを明示的にインスタンス化しているため、静的アサーションが発生します。明示的なインスタンス化にはメリットがあるため、削除は避けたいと思います (メリットについては上記を参照してください)。

私は最近次のコードを見ました：

期待どおりに機能しますか（BOOST_STATIC_ASSERTのように）？

私は、一種の貧しい人のシングルトンとして機能する静的属性のみで構成されるクラスを持っています。その目的は、アプリケーションのさまざまなポイントから統計を収集することです。単体テストでは、実稼働コードとの違いを取得するために使用できるシャドウ コピーを作成しました。

例：

すべてのメンバーは静的であるため、シャドウ クラスはプロダクション クラスから継承できず、プロダクション クラスの属性は副作用のある複雑なオブジェクトであり、比較のためにシャドウに単純な値のみを保持させたいと考えています。

シャドウ クラスの保守をいくらか容易にするために、静的アサートを追加して、誰かがプロダクション クラスに属性を追加するたびにシャドウ クラスも更新されることを確認したいと考えました。

属性が静的でない場合、これは次のようにすることで簡単に達成できたはずです。

クラスを非静的にする以外に、本番クラスを適切なシングルトンに変換する必要があるため、実行したくないのですが、現在の実装でこのチェックを実行できる方法はありますか?

実行時に、シャドウ内のすべての値を本番クラスで検証するメソッドがあります。新しい属性が追加されたときにメソッドも更新する必要があるため、検証された属性の数を数え、その量が属性の総数と異なるかどうかをアサートできるようにしたいと考えています。

例

私が使用できる GCC 拡張機能があれば、移植可能なものを好みますが、それは許容できる解決策になるかもしれません。

以前、引数が であるかどうかに基づく関数のオーバーロード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。

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

完全なエラーは

../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に多少の欠陥があることはすでにわかっています。これは同じバグのインスタンスですか？