C ライブラリが提供する assert に限定されるわけではありません。プロダクション/リリース ビルドでも動作する追加の assertion メカニズムを持つことは理にかなっています。
assert
生産/リリース ビルドを遅くしたくない高価な (CPU、キャッシュ ホース、データベースの負荷など) チェックには C ライブラリを使用します。
- 本番/リリースビルドでも実行したい安価なテストまたは非常に重要なテストには、独自のアサートメカニズムを使用します。失敗すると、プログラムがその後適切に動作することを信頼できないことが示されます。たとえば、プログラムのコアであるデータ構造が操作は明らかに破損しています
- エラーを報告して、さらに作業を行うのに役立つ状態に戻ることができると思われる場合は、例外/エラー コードなどを使用し、そのサービスを提供し続けることが優先されます。
したがって、あなたの例では:
std::vector<int> v = get_stuff();
ASSERT(v.size() == this->size());
a = v[this->size() - 1];
デバッグ モードのみの ASSERT を使用することも、本番環境でも開始される ASSERT を使用することも、前者に続いて...
a = v.at(this->size() - 1);
...問題が本番環境で発生した場合にキャッチして処理できる例外が発生するようにします。例外処理ケースのコード カバレッジを取得するには、運用ビルド用の単体テスト ケースを作成する必要があります。
心に留めておくべきことは、現実的で保守可能なバランスを見つけることです。実行時のエラー処理を徹底的に行おうとすると、コードのサイズと複雑さが 5 倍または 10 倍になり、テストの労力も増大する可能性があります。そのため、どこでどの程度処理するかを選択してください。単純なアサートやコア ダンプなどは比較的単純です。テスト ケースのない 1 つのライナーであり、より自由に使用できます。