注特価;このテクニカル ノートでは、Windows 3.1 用に書かれています。Windows NT はこれらの機能のほとんどを実装します。Windows 3.1 (Win32s Dll) でアプリケーションを実行すると、これらのテクニックのデバッグに役立つことができます。Windows 95 もを実装および配置 Windows 3.1 には堅牢性機能を拡張します。デバッグ バージョンの Windows 95 を実行しているアプリケーションを保証する最善の方法を実行してきれいです。(&N)。
Windows 3.1 Windows 3.0 は堅牢なアプリケーション開発の領域では大きな改善です。Windows 3.1 には、Windows アプリケーションの信頼性を高める新機能の数が含まれます。このテクニカル ノートでこれらの機能は MFC ライブラリ内の使用について説明します。
これらの機能には、デバッグ カーネル、厳格な型チェック、診断、メモリ管理、および、WINDOWSX が含まれます。H の機能強化。
Windows 3.1 デバッグ カーネル
注特価;このセクションは、Microsoft Visual C バージョン 1.5 を適用します。(&N)。
MFC アプリケーション デバッグ システム実行可能ファイルのテストは、おそらく、堅牢で信頼性の高いアプリケーションがあるかどうかを確認することができる最善のことです。すべての種の役に立つエラー、デバッグ出力メッセージで発生する問題を知らせるチェック システムの実行可能ファイルのデバッグ バージョンを実行します。
2 つのマシンでデバッグ システムを使用する最善の方法である: デバッグ システムをインストールして、開発用コンピューター テストのデバッグは、マシンをしています。テスト コンピュータの 1 台のマシンは、常にデバッグ カーネルを実行してください。他のマシンは、開発コンピュータ非デバッグ カーネルを実行する必要があります。デバッグ カーネルからの出力、プライマリ コンピューターに null モデム回線を介して送信できます。[1 台のマシンだけがある場合は、(がパフォーマンスが若干低下) デバッグ カーネルを実行することを確認する必要があります。デバッグ カーネルからの出力は、DBWIN は、Microsoft の Visual C バージョン 1.5 に付属のツールにルーティングできます。さらに、Visual の C++ 出力ウィンドウ出力、デバッガを実行すると受け取る。
単一のコンピューターをデバッグ用に便利なトリック システムとデバッグ バイナリおよびシンボルのコピーを別のディレクトリに配置し、適切なファイルを Windows システム ディレクトリにコピーするバッチ ファイルです。この方法は Windows を終了し、すばやくデバッグと非デバッグ切り替えることができます。Visual C バージョン 1.5 のインストール プログラムこの設定は、デバッグと非デバッグ バージョンの Windows の D2N を切り替えることができます。バットと N2D。バット バッチ ファイル。
デバッガーとデバッグ ターミナルを実行していない場合は、エラーとデバッグ システムによって生成された警告メッセージを見ることができますので、DBWIN アプリケーションを実行してください。このアプリケーションは、Visual C バージョン 1.5 が含まれています。
以下は頻繁に出荷の Windows アプリケーションで表示されるいくつかの一般的なプログラミング エラーです。これらの問題の多くは、ランダム システム UAEs と Windows 3.0 の下で他の問題を引き起こすことができます。ような問題を追跡に役立つデバッグ システム バイナリ:
MFC の診断
さらに、Microsoft Foundation Classes をコンパイル、リンク、ライブラリのデバッグ ビルドでのみ堅牢性機能のセット同梱 (で終わるそれらライブラリのバリアントをいた ')。これらの機能を記述し、設計のクラスでランタイムおよびコンパイル時のエラー トラップをアプリケーションの大幅に向上します、アプリケーションを使用します。これらの関数が以下ですが、すべて、クラス ライブラリのリファレンスマニュアルに記載されています。
MFC のCObjectから派生したすべてのクラスは、ASCII 形式で、オブジェクトの状態を表示することができます、ダンプメンバー関数を実装します。この関数は、デバッガーから呼び出すまたは #ifdef _DEBUG/#endif の部分をコード内に配置します。ヘルパー関数AfxDumpデバッグ ライブラリでこの目的のためにだけ含まれています。それは、1 つのパラメーターと、CObject ※ と呼ばれます。Out 引数を印刷するには、デバッガーからこの関数を呼び出すことができます。ダンプのメンバーを実装するクラスを指定する必要があります。AssertValid の場合と同様と、最初に明示的に、基本クラスのDumpメンバー関数呼び出す必要があります。ダンプの出力は、標準 MFC CDumpContextは既定では、デバッガーの出力ウィンドウに、または、デバッグ ターミナルにafxDumpにルーティングされます。DBWIN プログラムを使用して、 afxDumpの出力を表示することもできます。ソース ファイル MFC\SRC\DUMPINIT。CPP にはafxDumpを別の宛先にルーティングする方法に関する情報が含まれています。
トレースprintf、 afxDumpにルート出力のみのようには動作するマクロ。トリッキーなまたは特別な場所でコードを示すためにトレースステートメントを使用する必要があります。堅牢性の他の機能、トレースのみデバッグ ライブラリでは、意味があるし、製品版ビルドでは無効です。メッセージの流れを追跡するためのトレースステートメントの構築、MFC ライブラリには数が含まれます。デバッグ トレースの詳細についてはテクニカル ノート 7を参照してください。
ASSERTは、ランタイム チェックの有効性はステートメントのです。ASSERTs 自由、プログラム全体で使用します。コメント、効果がある任意の場所:
//lpStr は NULL をこの時点でする必要があります
あなたは、実行時の assert を置き換える必要があります。:
ASSERT(lpStr == NULL)
コンパイラはコメントを理解することはできませんが、アサーション マクロで式を評価できます。ASSERTステートメントの小売価格のビルドでは効果があります。製品版ビルドでは、 ASSERTからの情報が必要な場合は、[ VERIFYマクロを使用します。
MFC には、広範な診断メモリ アロケーターも含まれています。診断メモリ アロケーターを使用して、特定のプログラムの機能の中にすべてのメモリ リソースを解放することを確認します。診断アロケーターは、ソース ファイルと行を追跡するCMemoryState::DumpAllObjectsSince API を使用する場合は、残っているすべての割り当てを見つけることができますので、割り当ての数。
既定では、MFC (ある場合)、プログラムを終了する前に、プログラムによって解放されないすべてのオブジェクトをダンプします。この出力を表示するには、デバッガーでアプリケーションを実行します。
Windows 3.1 を厳密な型チェック
厳格な型チェック、WINDOWS で使用可能なオプションです。H ヘッダー ファイル。既定では、このような厳格なMFC を使用して MFC アプリケーションを構築する場合はそれらを使用する必要があります。MFC がサポートされなく、厳格なインクルードファイルせずアプリケーションの構築。
タイプセーフなリンケージと厳格な
これらの関数が異なる仮パラメーター リストがある限り、C++ で多くの関数と同じ名前に許可されます。独自のリンクのシンボルがあるには、C++ コンパイラ」、関数呼び出し規約等の仮パラメーターの型、名前、数などの情報をエンコード アルゴリズムを使用してこれらの名前装飾されます」。
この新しく生成された名前は、関数の外部リンク シンボルとして使用されます。これは、タイプセーフなリンケージとして知られている、C++ の大きな利点です。関数は extern"C"ブロック内でこの名前の装飾は適用されません、その理由は WINDOWS のすべての Api。H） は、このようなブロックで。
厳格な型の WINDOWS でをチェックします。H は、タイプ セーフの Windows プログラムの種類を使用して、windows のすべての異なるハンドルを向上します。したがって、たとえば、厳格な誤って、 HPEN HBITMAPを期待してルーチンを通り抜けるを防ぎます。
Extern"C"{} ブロック内ですべての Windows Api であるため、上記の方法で装飾はありません。厳格な一意 (具体的には、異なるポインター型、明示的なキャストを行わない自由に変換することはできません処理の s を使用) する、さまざまな Windows の typedef の種類を変更します。
場合は、厳格な型が 1 つのファイルを別のチェックがある有効で、見ることができるように、C++ コンパイラ異なる外部リンク シンボルを 1 つの関数を生成します。これは、リンク時エラーが発生します。したがって、C モジュール (方で終わるだけチェック厳格な型を使用することをお勧めC). コードを正常にコンパイルすると、 STRICTの利点は完全に実現されますのでまた、厳格なコンパイル時のみオプションです。
STRICTを混合している場合と非-厳格なコードする必要があるのリンケージの矛盾を認識します。一般に、すべての MFC プログラミングすべて C++ STRICTを行う必要があります。従来の C コードがある場合は、[ STRICTを使用しないが許容です.
Windows 3.1 WINDOWSX。H ヘッダー ファイル
Windows 3.1 と Win32、WINDOWSX は新しいです。C. 使用 Windows プログラマの C コーディング スタイルの様々 な拡張機能をサポートする H ヘッダー ファイルこれらのマクロの Api、メッセージ クラッカーと制御 Api を WINDOWSX が定義されます。H。
この構文は、主に c 言語のプログラマに設計されています。MFC の WINDOWSX の使用をサポートしています。依存する既存のコードがある場合は、これらを緊張、H、MFC で変更せずにこのコードを使用します。場合、ただし、MFC 匹敵イディオム WINDOWSX の機能のすべてをすることが。H、および C++ を使用して言語より多くの意味と建築の安全性のこれらのタスクを実行するには。
WINDOWSX を使用するには。H、# を必ず AFXWIN 含まれている前に、それが含まれます。H （または STDAFX。AppWizard の構造を使用している場合の H)。
唯一の警告は、2 つの WINDOWSX があることです。衝突する H Api、MFC の C++ Api では。2 つの Api SubclassWindowとだけならば copyrgn 関数は MFC 内で使用するため使用できません。これらのいずれかを使用する MFC API (およびクラス) を変換する、または Windows API を直接呼び出す必要があります。異なる名前を持つ限り、[独自のマクロ コードを記述することもできます。
番号順テクニカル ノート|nbsp;カテゴリ別テクニカル ノート(&N)