「ポータブル」と「マクロ」という言葉がしばしば一緒にならないことは知っていますが、私のコードは通常、#ifdef _DEBUG目的の結果を確認するタグ (私は VS2012 を使用) でいっぱいです。コードを Unix システムに移植できるようにしたいと考えています。
この投稿に基づく私の理解では、Visual Studio は を使用_DEBUGし、C 標準は を使用しますNDEBUGが、それらの機能は異なります (_DEBUGフラグ デバッグ モード、NDEBUGフラグ アサーション)。
コードを可能な限り移植可能にし#ifndef NDEBUGたい場合、アサートがアクティブなときにのみそれらのコード行を実行したい場合に使用する必要がありますか? Visual Studio 内でこれがもたらす結果は何ですか? 動作しているように見えますが、不足しているものがないことを確認したいです。すなわち。_DEBUG完全に優れたC標準の代替手段があるのに、なぜMicrosoftは使用するのでしょうか? 歴史的な理由？
その船はずっと前に出航しましたが、MSVC は抵抗が無駄だったので従いました。これは期待どおりに機能します。
#ifdef NDEBUG
#pragma message("Release build selected")
#endif
そのマクロは、いくつかのように空から完全に落ちるわけではありません。プロジェクト + プロパティ、C/C++、プリプロセッサ、プリプロセッサ定義の設定。これは、コンパイラが Borg に参加したからではなく、IDE が参加したからです。もう少し具体的に言うと、プロジェクト テンプレートがそうでした。非常に良い言い訳:)
いいえ、マクロを移植可能にすることはまったく問題ではありません。メイクファイルを正しくするだけです。
MS が NDEBUG マクロを使用せず、代わりに _DEBUG を定義する本当の理由はわかりません。私の推測では、それは の_ASSERT代わりにの定義に関連していると思いassertます。
問題は、C 標準の定義では、コンソールとプログラムassert()に行を出力する必要があることです。abortしかし、通常、Windows プログラムにはコンソールがありません。そのため、MS は代わりにウィンドウをポップアップ表示するのがよいと考えました。しかしassert()、ウィンドウをポップアップ表示すると標準に準拠していないため、類似しているが異なるマクロ:_ASSERTと、その動作を制御する別のマクロ: が開発されました_DEBUG。
_UNICODEおよびUNICODEマクロにも同様の混乱が存在しますが、それは別の話です...
Visual C++ プロジェクトの既定の構成では、デバッグ モード_DEBUGで が定義されていますが、定義されNDEBUGていないことに注意してください。解放モード中_DEBUGは定義されていませんが、定義されていNDEBUGます。したがって、独自のコードでは、それらのいずれかを使用できます。しかし当然のことながら、名前はコンパイラの実装に予約されているためNDEBUG、移植可能にしたい場合は を使用する必要があります。_DEBUG
私の知る限り、（標準で）NDEBUG影響を受けるのはassertマクロだけです。したがって、デバッグ機能を追加したい場合は、_DEBUG(に影響したり依存したりしないNDEBUG) のような独自のマクロ定義を追加します。
デバッグ コードを移植可能にするには、同じ目的で独自のマクロを定義する方がよいでしょう。
NDEBUG次に、オプションとして、プレゼンスに応じて、オンとオフを切り替えることができます。
少し不自然ではありますが、これを行うと、多少ポータブルになります
#if defined(__unix__) && defined(NDEBUG)
#define _DEBUG
#endif