6

Visual C++ コードベースを確認しているときに、次のような奇妙なことがわかりました。実行時アサート (条件をチェックし、条件に違反している場合は例外をスローする) は、コンパイル時に条件を評価できる場合に使用されました。

assert( sizeof( SomeType ) == sizeof( SomeOtherType ) );

明らかに、コンパイラは条件を評価し、効果的に次のいずれかになるコードを置き換えます

assert( true );

何もしない、または

assert( false );

コントロールがその行を通過するたびに例外をスローします。

IMO では、次の理由により、代わりにコンパイル時のアサートを使用する必要がありました。

  • コンパイル時に条件違反を早期に公開し、
  • よりクリーンな（したがって、より高速で小さい）マシンコードを発行できます

コンパイル時のアサートだけが正しいようです。ここでランタイムアサートを好む理由はありますか?

4

2 に答える 2

17

ここで実行時アサートを好む理由はありません。実行時エラーよりもコンパイル時エラーを優先する必要があるため、2 つのオプションのどちらかを考えれば、実行時アサートを選択する理由はありません。

ただし、静的アサートがオプションではない場合 (静的アサートの概念がわからない、作成方法がわからず、使用可能なものがない、または作成方法はわかっているが利用できない場合)。までの時間)、実行時のアサートは次善の策です。

C++0x では、組み込みstatic_assert機能によって、コンパイル時のアサートが機能する場合に実行時のアサートを使用するすべての理由が終了するはずです。

于 2010-09-07T14:05:07.210 に答える
4

文脈なしではわかりません。テンプレート コードでは、一部のインスタンス化で一部のブランチに到達できない場合があります。コンパイル時のアサートは、関数全体の形式が崩れてしまうため、不適切です。アンassert(<type-dependent expression>)はしません。

例えば

template <typename T> void foo(T t)
{
  if (t < 0) {
    assert(std::numeric_limits<T>::min() < 0);
    T u = t - std::numeric_limits<T>::min();
  }
}

ランタイム アサートが決して失敗しない場合でも、アサートを静的アサートに変換することはできません。

于 2010-09-07T14:27:45.110 に答える