アサーション

[アーティクル]
03/12/2013

アサートステートメントは、プログラムの時点で真であると想定する条件を指定します。この条件が true でない場合、アサーションは失敗し、プログラムの実行が停止し、アサーションに失敗しました]ダイアログボックスが表示されます。

Visual C++ は、次の構成に基づくアサートステートメントをサポートします:

MFC プログラムの MFC アサーション。
ATLASSERT (ATL を使用するプログラムの場合)
CRT アサーション (C ランタイムライブラリを使用するプログラムの場合)
ANSI assert 関数 (その他の C/C++ プログラムの場合)

およびテストエラー状態チェックするロジックを、エラーの結果を処理する必要がある操作の特定にアサーションを使用できます。

このトピックの内容

アサーションのしくみ

デバッグビルドとリリースビルドのアサーション

アサーションの副作用

CRT アサーション

MFC アサーション

MFC ASSERT_VALID と CObject::AssertValid
AssertValid に関する制限事項

アサーションを使用する

論理エラーのキャッチ
結果のチェック
ハンドルされないエラーを検索

アサーションのしくみ

デバッガーが MFC には、または 15 B のランタイムライブラリアサーション停止すると、ソースが使用できる場合、デバッガーはアサーションが発生したソースファイルの時点に移動します。アサーションメッセージは [出力ウィンドウ] と [アサートに失敗しました] のダイアログボックスの両方に表示されます。後で参照するためにアサーションメッセージを保存する場合は、[出力] ウィンドウからテキストウィンドウへコピーします。[出力] ウィンドウに、他のエラーメッセージが表示されていることもあります。アサーションが失敗した原因を突き止める手掛かりとなるため、これらのエラーメッセージをよく調べてください。

開発中のエラーを検出するには、アサーションを使用します。一般に、各コンポーネントのデータには、1 とおりのアサーションを使用します。引数が null でないと仮定した場合、たとえばこの仮定をテストするには、アサーションを使用します。

このトピックの内容

デバッグビルドとリリースビルドのアサーション

アサートステートメントは _DEBUG が定義されている場合のみコンパイルされます。それ以外の場合、コンパイラは null ステートメントとしてアサーションを処理します。したがって、アサートステートメントは、プログラムの最終リリースやパフォーマンスのオーバーヘッドコストを強制しません。また、#ifdef ディレクティブの使用を避けることができます。

アサーションの副作用

アサーションをコードに追加するときは、そのアサーションに副作用がないことを確認してください。たとえば、nM の値を変更する次のアサーションを検討する:

ASSERT(nM++ > 0); // Don't do this!

ASSERT の式がプログラムのリリースバージョンで評価されないため、nM にデバッグバージョンとリリースバージョンの異なる値があります。MFC でこの問題を回避するには、ASSERTの代わりに [検証] マクロを使用できます。VERIFY は、すべてのバージョンの式が評価されますが、リリースバージョンの結果をチェックしません。

アサートステートメントで関数を呼び出す場合は、その関数の評価によって予想外の副作用が生じることがあるため特に注意してください。

ASSERT ( myFnctn(0)==1 ) // unsafe if myFnctn has side effects
VERIFY ( myFnctn(0)==1 ) // safe

VERIFY は、デバッグバージョンとリリースバージョンの両方の myFnctn を呼び出し、したがって使用してもかまいません。ただし、VERIFY を使用してリリースバージョンの不要な関数呼び出しのオーバーヘッドを伴います。

このトピックの内容

CRT アサーション

CRTDBG.H ヘッダーファイルには、アサーションによるチェックを行うための _ASSERT マクロと _ASSERTE マクロが定義されています。

マクロ	結果
_ASSERT	指定した式が FALSE と評価された場合、_ASSERT 対象のファイル名と行番号を出力します。
_ASSERTE	_ASSERT と同様の結果と共に、アサートされた式の文字列形式も出力します。

FALSE と評価されたアサート対象の式もレポートするため、_ASSERTE マクロの方が強力です。このマクロを使用すると、ソースコードを参照しなくても問題を識別できます。ただし、アプリケーションのデバッグバージョンに、_ASSERTE を使用してアサートした式ごとに文字列定数が含まれることになります。_ASSERTE マクロを多用すると、これらの文字列式がかなりのメモリを占有します。これが問題となる場合は、_ASSERT マクロを使用してメモリを節約してください。

_DEBUG が定義されている場合、_ASSERTE のマクロは次のように定義されます:

#define _ASSERTE(expr) \
   do { \
      if (!(expr) && (1 == _CrtDbgReport( \
         _CRT_ASSERT, __FILE__, __LINE__, #expr))) \
         _CrtDbgBreak(); \
   } while (0)

アサート対象の式が FALSE と評価された場合、_CrtDbgReport が呼び出され、アサーションが失敗したことをレポートします。既定では、メッセージダイアログボックスが表示されます。メッセージダイアログボックスの [再試行] を選択すると、_CrtDbgReport は 1 を返し、_CrtDbgBreak は DebugBreakによってデバッガーを呼び出します。

ヒープ破損のチェック

次の例は、_CrtCheckMemory を使用してヒープの破損をチェックします。

_ASSERTE(_CrtCheckMemory());

ポインターの有効性チェック

次の例は、_CrtIsValidPointer を使用して、指定したメモリ範囲への読み書きが有効かどうかを検証します。

_ASSERTE(_CrtIsValidPointer( address, size, TRUE );

次の例は、_CrtIsValidHeapPointer を使用して、ポインターがローカルヒープ上のメモリを指しているかどうかを検証します。ここでのローカルヒープとは、C ランタイムライブラリのこのインスタンスによって作成および管理されるヒープを指します。DLL はライブラリの独自のインスタンスを持っているため、アプリケーションヒープの外部に独自のヒープを所有していることになります。このアサーションは、null アドレスや範囲外のアドレスだけでなく、静的変数、スタック変数、その他の非ローカルメモリを指すポインターも検出します。

_ASSERTE(_CrtIsValidPointer( myData );

メモリブロックのチェック

次の例は、_CrtIsMemoryBlock を使用して、メモリブロックがローカルヒープ上にあり、有効なブロック型を持つかどうかを検証します。

_ASSERTE(_CrtIsMemoryBlock (myData, size, &requestNumber, &filename, &linenumber));

このトピックの内容

MFC アサーション

MFC には、アサーションによるチェックを行うための ASSERT マクロが定義されています。また、CObject派生オブジェクトの内部状態をチェックするための MFC ASSERT_VALID と CObject::AssertValid のメソッドを定義します。

MFC の ASSERT マクロの引数がゼロまたは false に評価された場合、マクロはプログラムの実行を停止し、ユーザーに警告します; それ以外の場合、実行が継続されます。

アサーションが失敗すると、メッセージダイアログボックスにアサーション対象のソースファイル名と行番号が表示されます。このダイアログボックスで [再試行] を選択すると、AfxDebugBreak が呼び出され、プログラムの実行が停止してデバッガーが起動します。この時点で、コールスタックをチェックし、アサーションが失敗したかを確認するには、そのほかのデバッガー機能を使用できます。Just-In-Time デバッグを有効にし、デバッガーが既に走らなかったらダイアログボックスは、デバッガーを起動できます。

次の例では、関数の戻り値をチェックする ASSERT を使用する方法を示しています:

int x = SomeFunc(y);
ASSERT(x >= 0);   //  Assertion fails if x is negative

ASSERT を次のように IsKindOf 関数と組み合わせて使用すると、関数の引数の型をチェックできます。

ASSERT( pObject1->IsKindOf( RUNTIME_CLASS( CPerson ) ) );

ASSERT のマクロは、リリースバージョンのコードを生成しません。リリースバージョンで式を評価する必要がある場合は、ASSERT の代わりに VERIFY マクロを使用してください。

MFC ASSERT_VALID と CObject::AssertValid

CObject::AssertValid メソッドを使用すると、オブジェクトの内部状態を実行時にチェックできます。CObject からクラスを派生させる場合、必ずしも AssertValid をオーバーライドする必要はありませんが、そうすることによって、クラスの信頼性を高めることができます。AssertValid は、有効な値が含まれていることを確認するために、オブジェクトのメンバー変数すべてのアサーションを実行します。たとえば、ポインターのメンバー変数が NULL でないかどうかをチェックできます。

AssertValid 関数の宣言方法を次に示します。

class CPerson : public CObject
{
protected:
    CString m_strName;
    float   m_salary;
public:
#ifdef _DEBUG
    // Override
    virtual void AssertValid() const;
#endif
    // ...
};

AssertValid をオーバーライドするときは、派生クラス独自のチェックを行う前に、基本クラスの AssertValid を呼び出します。その後で、ASSERT マクロを使用して、派生クラス独自のメンバーをチェックします。次に例を示します。

#ifdef _DEBUG
void CPerson::AssertValid() const
{
    // Call inherited AssertValid first.
    CObject::AssertValid();

    // Check CPerson members...
    // Must have a name.
    ASSERT( !m_strName.IsEmpty());
    // Must have an income.
    ASSERT( m_salary > 0 );
}
#endif

オブジェクトを格納しているメンバー変数がある場合は、ASSERT_VALID マクロを使用して、そのオブジェクトの内部状態が有効かどうかを検証します (オブジェクトのクラスが AssertValid をオーバーライドしている場合)。

たとえば、CMyData クラスのメンバー変数の 1 つに CObList が格納されているとします。CObList 型の変数 m_DataList は、CPerson オブジェクトのコレクションを格納します。CMyData クラスの宣言の概要を次に示します。

class CMyData : public CObject
{
    // Constructor and other members ...
    protected:
        CObList* m_pDataList;
    // Other declarations ...
    public:
#ifdef _DEBUG
        // Override:
        virtual void AssertValid( ) const;
#endif
    // And so on ...
};

CMyData クラスでオーバーライドした AssertValid は次のようになります。

#ifdef _DEBUG
void CMyData::AssertValid( ) const
{
    // Call inherited AssertValid.
    CObject::AssertValid( );
    // Check validity of CMyData members.
    ASSERT_VALID( m_pDataList );
    // ...
}
#endif

CMyData クラスは、AssertValid の機構を使用して、データメンバーに格納されているオブジェクトの有効性を検証します。CMyData クラスでオーバーライドした AssertValid は、独自の m_pDataList メンバー変数に対して ASSERT_VALID マクロを呼び出します。

有効性のテストは、クラス CObList も AssertValidをオーバーライドするため、このレベルでは停止しません。このオーバーライドにより、そのクラスが表すリストの内部状態の有効性も検証されます。つまり、CMyData オブジェクトの有効性を検証すると、そのメンバー変数に格納されている CObList リストオブジェクトの内部状態の有効性も検証されることになります。

さらにコードを追加すると、リストに格納されている CPerson オブジェクトの有効性も検証できます。たとえば、CObList から派生クラス CPersonList を生成し、AssertValid をオーバーライドできます。このオーバーライドでは、CObject::AssertValid を呼び出した後、リストに格納されている CPerson オブジェクトごとに AssertValid を呼び出すことによってリストを反復処理します。CPerson クラスは、このトピックの冒頭に示したように、既に AssertValid をオーバーライドしています。

これらの関数やマクロは、デバッグバージョンのビルドに強力な機構を提供します。リリースバージョンのビルド時には、この機構は自動的にオフになります。

AssertValid に関する制限事項

この関数は、オブジェクトが不正な場合に、アサートしてプログラムの実行を停止します。ただし、アサートされない場合でも、問題が検出が、オブジェクトに問題が保証されることだけを示しています。

このトピックの内容

アサーションを使用する

論理エラーのキャッチ

プログラムの論理に従えば true になるはずの条件にアサーションを設定しておきます。論理エラーが発生しない場合、このアサーションは特に機能しません。

たとえば、容器内の気体分子をシミュレートすると想定し、変数 numMols で分子の総数を表すことにします。この数値が 0 より小さくなることはあり得ないため、次のような MFC アサートステートメントを挿入しておきます。

ASSERT(numMols >= 0);

または、次のように CRT アサーションを挿入することもできます。

_ASSERT(numMols >= 0);

プログラムが正しく動作していれば、これらのステートメントは何の処理も行いません。ただし、論理エラーにより numMolsを未満であるためには、アサートこれらのステートメントは、プログラムの実行を停止し、[アサートに失敗しました] ダイアログボックスを表示します。

このトピックの内容

結果のチェック

アサーションは、結果が視覚的に、マニフェストからテストの操作のために役立ちます。

たとえば、次のコードを検討してみます。このコードは、mols の指すリンクリストの内容に基づいて変数 iMols を更新します。

/* This code assumes that type has overloaded the != operator
 with const char * 
It also assumes that H2O is somewhere in that linked list. 
Otherwise we'll get an access violation... */
while (mols->type != "H2O")
{
 iMols += mols->num;
 mols = mols->next;
}
ASSERT(iMols<=numMols); // MFC version
_ASSERT(iMols<=numMols); // CRT version

iMols でカウントされる分子の数は、必ず分子の総数 numMols 以下であることが必要です。このループを目で見ただけでは必ずそうなるかどうかを確認できないため、ループの後にアサートステートメントを挿入し、その条件が満たされているかどうかをチェックします。

このトピックの内容

ハンドルされないエラーを検索

アサーションを使用すると、コード内のエラー処理が完了しているはずの個所で、エラー条件をチェックできます。次の例のグラフィックルーチンは、エラーコードを返します。または、正常終了した場合は 0 を返します。

myErr = myGraphRoutine(a, b);

/* Code to handle errors and
   reset myErr if successful */

ASSERT(!myErr); -- MFC version
_ASSERT(!myErr); -- CRT version

エラー処理コードが正しく機能していれば、アサートステートメントに達する前に、発生したエラーは処理され、myErr は 0 にリセットされるはずです。myErr に別の値が格納されている場合は、アサーションが失敗し、プログラムの実行が停止して [アサートに失敗しました] ダイアログボックスが表示されます。

ただし、アサートステートメントは、エラー処理コードに代わるものではありません。最終リリースバージョンのコードで問題となる可能性のあるアサートステートメントの例を次に示します。

myErr = myGraphRoutine(a, b);

/* No Code to handle errors */

ASSERT(!myErr); // Don't do this!
_ASSERT(!myErr); // Don't do this, either!

このコードは、アサートステートメントを使用してエラー条件を処理しています。その結果、myGraphRoutine が返すエラーコードは、最終リリースバージョンのコードでは処理されないままになります。

このトピックの内容

参照

概念

デバッガーのセキュリティ

その他の技術情報

ネイティブコードのデバッグ

Share via

アサーション

このトピックの内容

アサーションのしくみ

デバッグビルドとリリースビルドのアサーション

アサーションの副作用

CRT アサーション

ヒープ破損のチェック

ポインターの有効性チェック

メモリブロックのチェック

MFC アサーション

MFC ASSERT_VALID と CObject::AssertValid

AssertValid に関する制限事項

アサーションを使用する

論理エラーのキャッチ

結果のチェック

ハンドルされないエラーを検索

参照

関連項目

概念

その他の技術情報

その他のリソース

Share via

アサーション

このトピックの内容

アサーションのしくみ

デバッグ ビルドとリリース ビルドのアサーション

アサーションの副作用

CRT アサーション

ヒープ破損のチェック

ポインターの有効性チェック

メモリ ブロックのチェック

MFC アサーション

MFC ASSERT_VALID と CObject::AssertValid

AssertValid に関する制限事項

アサーションを使用する

論理エラーのキャッチ

結果のチェック

ハンドルされないエラーを検索

参照

関連項目

概念

その他の技術情報

その他のリソース

デバッグビルドとリリースビルドのアサーション

メモリブロックのチェック