問題タブ [precompiled-headers]

プリコンパイルヘッダーに非常に奇妙な問題がありました。.cpp ファイルにメソッドを実装すると、リンカが LNK2019: unresolved external symbol エラーを生成します。ただし、メソッドを .h ファイルに実装すると、プログラムをコンパイルできます。たまたま解決策を見つけましたが、このエラーの根本的な原因についてはわかりません。

私のプロジェクト構造は次のようになります

ソリューション
-> プロジェクト 1
-> プロジェクト 2

プロジェクト 1 には 3 つのファイルがあります。ああ、A.cpp と stdafx.h

プロジェクト 2 では、A クラスを使用したいと考えています。

ファイルwhatever.cpp

コンパイル時に、リンカは A 構築関数の未解決の外部シンボル エラーを報告します。コンストラクターを Ah ファイルに実装するとします。project2 は正常に準拠できます。知りたいのですが、実装を A.cpp ファイルに入れられないのはなぜですか? プリコンパイルヘッダーを整理する正しい方法は何ですか?

ありがとうございました

複数のプラットフォーム用に C++ を開発しているため、ビルド プロセスに SCons を使用することを調査しています。ビルド構成は 99%完了していますが、Windows でプリコンパイル済みヘッダー ファイルに関係する非常に奇妙なエラーが発生しています。さらに奇妙なのは、それが 1 つのプロジェクトでのみ発生することです。

このプロジェクトの SConscript ファイルには、Windows で PCH をコンパイルするための次のものが含まれています。

また、プロジェクト内のすべてのファイルに MyPCH.h を強制的に含めるようにコンパイラ フラグを設定しています。

すべてがうまくいき、完全にうまくコンパイルされます。次のようなリンカ エラーのページやページが表示されるのは、最終的な DLL リンク ステージまでではありません。

と：

これは不可解です。なぜなら、私がリンク警告を受け取っているクラスはどれもboost::asioを使用していないからです.

さらに困惑するのは、プリコンパイル済みヘッダー ファイルのコンパイルを無効にしても、インクルードを強制すると、すべてが正常にコンパイルおよびリンクされることです。それはただ永遠におかしくなります。

これらのリンカ エラーの原因について何か手がかりを持っている人はいますか?

前もって感謝します。

- - 編集 - -

SCons が PCH を構築するために出力しているコマンド ラインを次に示します (マイナス インクルード パス)。

コンパイル中のファイルのコマンド ラインを次に示します (ここでもインクルード パスは省略しています)。

最後に、リンク コマンド ラインを次に示します。

また、PCH ヘッダーは個々のファイルごとに明示的に含まれているわけではありませんが、コマンド ライン オプションでは、プロジェクトでコンパイルされたすべてのファイルに PCH を強制的に含める /FI があります。

#include "stdafx.h"プリコンパイル済みヘッダーを使用する場合、すべてのファイルが必要ですか? または、ソースファイルのみに含める必要がありますか。

編集:また、私のプリコンパイル済みヘッダー ファイル#includesには多くの STL ヘッダーが含まれています。しかし、私のヘッダーには、返される関数std::vectorやそのようなものが時々あるので、#include <vector>とにかくする必要があります。これは stdafx.h をインクルードするより悪いですか? 単体テスト フレームワークの定義を含める必要があります。

私はMSVC++6を使用して非常に大きなプロジェクトを構築しています。このプロジェクトのソースファイルの一部は、アプリケーションの保守に使用する小さなユーティリティと共有されています。以前は、この小さなユーティリティには、メインアプリからの多くのライブラリに対するリンクが必要であり、実行時にメインアプリのDLLも必要でした。私はこれらの依存関係を削除する必要がありましたが、これは非常に単純に聞こえました...残念ながら、メインアプリで使用されるプリコンパイル済みヘッダーが多くの問題を引き起こしています。

最初にユーティリティ内のすべてのファイルを作り直して、必要なものをすべて明示的に含め、次にPCHの#includeディレクティブを削除しました（これにより、ユーティリティの不要な依存関係の95％が削除されました）。これは、ユーティリティのコンパイルに最適です。ただし、メインアプリをコンパイルすると、プリコンパイル済みヘッダーディレクティブが見つからないというエラーが発生します。「素晴らしい、条件付きでPCHを含める」と思いました。これは機能していないようです...ここで説明したように、「予期しない#endif」が発生します。私の次の考えは、ユーティリティとメインアプリの間で共有される3つのソースファイルのメインアプリでPCHをオフにすることでした。これは正常にコンパイルされますが、リンク中に次のようなエラーが発生します。

AFAICT、複数定義されたシンボルはすべて、PCHの必要性を回避するために、共有ファイルに明示的に含めるシンボルです。私の勘では、これら3つのファイルをPCH .cppファイルと同じDLLにリンクしているため、複数の場所でコンパイルされます。この混乱から抜け出す方法はありますか？何でもやってみます...

いくつかのアンマネージクラスをそれらのマネージドクラスに置き換えるために、混合モードDLLを作成しようとしています。これを「クライアント」と呼びましょう。私の個人用マシンではすべて正常に動作しますが、ソースコードをチェックインすると、ビルドマシンでプロジェクトがビルドされません。「コア」と呼ばれる別のDLLから使用しているマネージクラスを認識しません。

問題はプリコンパイル済みヘッダーに関係していると思います。理由は次のとおりです。

「Core」のクラスを使用するために、「Client」プロジェクトに「Core」プロジェクトへの参照を追加しました。この参照を削除してから、個人のマシンでプロジェクトをビルドしても、引き続き機能します。ただし、CLR PCHは、参照を削除した後は再コンパイルしません。CLR PCHを再コンパイルしてからプロジェクトをコンパイルすると、ビルドマシンで発生するのと同じエラーで失敗します。つまり、管理対象クラスが認識されません。

インポートしたDLLのマネージクラスは、プリコンパイル済みヘッダーで定義されているようです。私はこれを確認することができませんでしたが、それは私が持っている最良の推測です。誰かがこの問題について彼らが流すことができる洞察を持っていますか？混合DLLのプロジェクト参照は、管理対象PCHにフックを配置することで解決されますか？

再現する手順

以下は私には意味がありません：

1. クライアントにビルドしてもらいます。
2. クライアントからコアへの参照を削除します。クライアントをコンパイルします。クライアントはまだビルドします。これは予期されていません。
3. クライアントPCHを再コンパイルしてから、クライアントをコンパイルします。クライアントのコンパイルが失敗します：「コア」のクラスは未定義です。これは予想される動作です。
4. コアへの参照を追加し、コンパイルします。同じ理由でコンパイルクライアントが失敗します。これは予期されていません
5. クライアントPCHを再コンパイルしてから、クライアントをコンパイルします。クライアントは正常にコンパイルされます。

この実験からの私の結論は、参照はプリコンパイル済みヘッダーを介してプロジェクトに挿入され、少なくともビルドマシンでは、これが機能する方法で何かが壊れているということです。

昔、私はプリコンパイル済みヘッダーを使用していました。コンパイルを高速化するため、およびb。CodeWarrior、MPW、VS、ProjectBuilder、gcc、Intelコンパイラなどの複数の開発ツールをサポートしていたからです。

これで、32GBのRAMを搭載したMacProができました。

今はCMakeだけを使っています。

では、プリコンパイル済みヘッダーが本当に必要になるのでしょうか。

私が見たり知らなかったりする明らかな利点はありますか？

クロスプラットフォームのプリコンパイル済みヘッダーを作成するにはどうすればよいですか？多分それは私の人生も単純化するでしょう。

オープンソースのコードベースを見ると、次のコードに出くわしました:

現在、StableHeaders.h は、生成を強制するために「コントロール」cpp に含まれるプリコンパイル済みヘッダーです。いずれにせよ、プリコンパイル済みヘッダーの後に表示される 3 つのインクルードも StableHeaders.h ファイルに含まれています。私の質問は、プリコンパイル済みヘッダーをサポートしていないコンパイラでコード ベースがビルドされるように、これらのファイルが 2 回含まれているのでしょうか? とにかく、インクルードガード/ヘッダーキャッシングにより、複数のインクルードが冗長になると仮定しています...

EDITところで、stableheaders.hファイルにはwin32のチェックがあります（大まかに）ので、stableheaders.h内のインクルードがプリコンパイル済みヘッダーをサポートしないコンパイラーに含まれないと仮定します。

Visual C ++ 6にあるサンプルプロジェクト（私のものではありません）があります。これをVisualStudio2008に変換しようとしています。

古いプロジェクトはプリコンパイル済みヘッダーを使用しています。今の質問は次のとおりです。

1. プリコンパイル済みヘッダーとは何ですか？

2. 古いプロジェクトはプリコンパイル済みヘッダーを使用しているためです。Visual Studio 2008（新しいプロジェクト）でも使用します。しかし、「stdafx.hを含めるのを忘れましたか」というエラーが表示されます。問題を解決するために、すべてのソースファイルに「stdafx.h」を含めます。それは完璧に機能しました。しかし、古いプロジェクトでは、すべてのファイルに「stdafx.h」が含まれていませんでしたか？次に、各ソースファイルに「stdafx.h」を含めることをオプトアウトするにはどうすればよいですか。すべてのソースファイルが「stdafx.h」で定義されたインクルードファイルを必要とするわけではないため、必要なのはごくわずかです。それはどのように行われますか？

編集： プリコンパイル済みヘッダーの使用から一部のファイルを除外するにはどうすればよいですか？

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

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

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

プリコンパイル済みヘッダーは、大規模なプロジェクトで多くの時間を節約できるように見えますが、いくつかの落とし穴があるお尻の痛みでもあるようです。

プリコンパイル済みヘッダーを使用することの長所と短所は何ですか？具体的には、Gnu / gcc / Linux環境での使用に関連していますか？