問題タブ [stdafx.h]

単体テストを作成する必要があるレガシー コードがたくさんあります。どこでもプリコンパイル済みヘッダーを使用するため、ほとんどすべての .cpp ファイルが stdafx.h に依存しているため、テストを作成するために依存関係を解消することが難しくなっています。

私の最初の本能は、ほとんどの場合 #include ディレクティブを含むこれらの stdafx.h ファイルをすべて削除し、必要に応じてそれらの #includes をソース ファイルに直接配置することです。

これは、プリコンパイル済みヘッダーが停止する場所を決定するために stdafx.h のようなファイルを持つことに依存しているため、プリコンパイル済みヘッダーをオフにする必要があります。

stdafx.h 依存関係なしでプリコンパイル済みヘッダーを保持する方法はありますか? この問題にアプローチするより良い方法はありますか?

いつものように、自分で理解できない何かで頭が混乱しているときは、皆さんに助けを求めます :)

今回は、なぜ stdafx.h がこのように機能するのか疑問に思っていました。私の理解では、それは2つのことを行います:

• 私たちが(?) 使用する可能性があり、めったに変更されない標準ヘッダーが含まれて います
• コードがプリコンパイルされなくなったときのコンパイラ ブックマークとして機能します。

さて、これら 2 つのことは、私には 2 つの非常に異なるタスクのように思えますが、なぜそれらを処理するために 2 つの別々の手順を実行しなかったのでしょうか? #pragma-command でブックマーク処理を行い、必要に応じて windows.h の長い行のヘッダー ファイルを使用して、頻繁に使用されるヘッダーをインクルードするのが合理的だと思われます...ポイント: stdafx.h を介して頻繁に使用されるヘッダーをインクルードする必要があるのはなぜですか? 個人的には、よく使用するヘッダーで、まだ独自のインクルードを行っていないものを認識していませんが、これらのヘッダーは .dll の生成に必要なのでしょうか?

事前にThx

Afxが何の略なのか興味があります。そして、FxCopのFxはどうですか？

stdafx.h を含む非常に多くのコードが表示されます。たとえば、プリコンパイル済みヘッダーは必要ありません。そして、必要なすべてのシステム ヘッダーを自分で手動でインクルードします。その場合、必要な場所を認識しておくべき他の正当な理由はありますstdafx.hか?

プリコンパイル済みヘッダー ( stdafx.h) を使用する Visual Studio C++ ベースのプログラムがあります。現在、gcc 4.x を使用してアプリケーションを Linux に移植しています。

問題は、両方の環境でプリコンパイル済みヘッダーを処理する方法です。私はグーグルで検索しましたが、結論に達することはできません。

stdafx.hコード ベースがかなり大きく、プリコンパイル済みヘッダーによってコンパイル時間が短縮されるため、当然、Visual Studio に残しておきたいと思います。

しかし、問題は Linux で何をするかです。これは私が見つけたものです：

1. そのままにしておきstdafx.hます。gcc は VC++ よりもかなり高速にコードをコンパイルします (または、私の Linux マシンの方が強力なだけです ... :)) ので、このオプションに満足しているかもしれません。

2. hereからのアプローチを使用します-次のようにしstdafx.hます（USE_PRECOMPILED_HEADERVSのみに設定）：

   /li>

3. hereのアプローチを使用してください -各 cpp ファイル/FIに暗黙的に含めるためにVC++ をコンパイルします。stdafx.hしたがって、VS では、コードを簡単に切り替えて、プリコンパイル済みヘッダーなしでコンパイルすることができ、コードを変更する必要はありません。
   私は個人的に依存関係が嫌いで、混乱stdafx.hが大きなコードベースを押し進めています。したがって、このオプションは私にとって魅力的です。Linuxstdafx.hでは/FI.

4. Linux ではstdafx.h、プリコンパイル済みヘッダーとしてのみコンパイルします (Visual Studio を模倣)。

あなたの意見？問題を処理するための他のアプローチはありますか?

ヘッダー（ah）をstdafx.hに配置し、そのヘッダーにstdafx.hに記載されていない別のヘッダー（bh）が含まれている場合、誰かがahを含めるたびにbhにアクセスしますか、それともahの一部としてコンパイルされますか？ahにコンパイルされた場合、誰かがbhを直接インクルードするとどうなりますか？これはプリコンパイルされますか？

この質問をする動機は、作業しているソフトウェアのstdafx.hファイルのコンテンツを最適化しようとしていることです。再構築時間と増分構築時間の両方が私たちにとって重要です。すべての.cppファイルで#includeディレクティブを検索し、各ファイルがインクルードされた回数を数えることができるかどうか疑問に思いました。含まれていることが多いファイルは、stdafx.hファイルの候補として適している可能性があります。もちろん、含まれているファイルだけでなく、含まれているファイルに含まれているファイルも考慮する必要がある場合、この戦略は完全に偽物です。

重要かどうかはわかりませんが、VisualStudio2005を使用しています。

2 つのプラットフォーム固有のstdafx.hファイルを .cpp ファイルに含めようとしていますが、#ifdef を実行しようとするとコンパイラがうまくいきません。

なぜ私が Mac コードで stdafx.h を使用しているのか不思議に思われるかもしれませんが、現時点ではそれは重要ではありません :)。

Windows でコードをコンパイルしようとすると、Fatal Error C1018が表示されます。他のヘッダーファイルを #ifdef で同じファイルに囲んでみましたが、コンパイラーは満足していました。したがって、Windows は stdafx.h を #ifdef することを好まないか、Windows は#include stdafx.h をファイルの最初の行にすることしか許可していないようです。

だから私の質問は、なぜですか？

カット

_CRTDBG_MAP_ALLOC を使用してメモリ リーク情報、特にファイルと行番号を取得したいのですが、最後に取得できません。私はこのようなものしか得ません：

{130} 0x00695128 の通常ブロック、16 バイト長。データ: <\ E Pi > 5C A5 45 01 02 00 00 00 01 00 00 00 E8 50 69 00

これはすべてのインクルードの前にある必要があることがわかりました：

そして、すべてのソースファイルのすべてのインクルードの後に​​これを追加することを推奨する人もいます:

ただし、main.cpp で明示的にメモリ リークを追加すると、出力に行番号が表示されます。だからそれはうまくいきますが、すべてではありません...

Boost ライブラリを使用しているため、メモリ リークはすべてこれらのどこかで発生していると思われます... (shared_ptr ?)。しかし、これらのメモリリークがどこから来たのかを知るにはどうすればよいでしょうか?

（.net）c ++ dllを使用する（com）c++プロジェクトがあります。プロジェクトはコンパイルされ、正常に実行されていました。

今、私がしたのはdllに変更を加えることだけで、致命的なエラーが発生しますc1083-（com）プロジェクトを再コンパイルするときにインクルードファイルstdafx.hを開くことができません。

これはどういう意味ですか？

ファイルの目的と、プリコンパイル済みヘッダーstdafx.hの意味は何ですか？