web-dev-qa-db-ja.com

ポインタがnullでないことをアサートしてもよいのはいつですか?

これは、次のようなコードセグメントのコードレビューの一部として登場しました。

auto somePikachu = GetMeAPikachu();
NT_ASSERT(somePikachu != nullptr); // this only fires on debug build
somePikachu->Thunderbolt();

somePikachunullの場合、Thunderboltを呼び出そうとすると、次の行でとにかくクラッシュするため、アサートは冗長であると私は考えています。 (もちろん、Thunderboltがこのポインターを逆参照する必要がない場合、リリースビルドでは何も起こりません)。したがって、主張は私見を何も購入していない。このアサートは読みやすさに付加価値を与え、デザインの意図を明確にするという意見の別の考え方があります。ポインターの有効性についてデザインをアサートする正しいパターンについてコミュニティの意見を聞きたいと思います。問題の説明に一致する他の可能なシナリオを自由に含めてください。

4
bashrc

アサーションの値は次のとおりです。

  • GetMeAPikachuがnull以外を返すというプログラマの想定を明示的に示しています。これは、履歴のある時点で関数が動作を変更した場合、または関数がnullを返すことができる特定の状況がある場合に特に価値がありますが、プログラマーはこれらの状況がここでは適用されないと主張しています。
  • これにより、エラー状態が「クラッシュが発生したので、原因を見つけてください」から「このポインタはnullでした」に変わります。
  • Thunderboltの実装の詳細には依存しません。その関数が仮想ではなく、メンバー変数自体にアクセスしない場合、クラッシュはまったく発生しないか、呼び出しツリー内の深いところで発生する可能性があり、アクセス違反ではなく、最終的には不正な命令である可能性があります無効な関数ポインター/ vtableをジャンプすることに成功しました。
9
Sebastian Redl