問題タブ [precompiled-headers]

VS2010 (VC100) を使用するように古いソリューションをアップグレードしようとしています。

stdafx.cpp が stdafx.h からプリコンパイル済みヘッダー stdafx.pch を作成するようにセットアップしました。次に、stdafx.h を含む他のすべての .cpp ファイルは、プリコンパイル済みヘッダーを使用するように指示されます。

これらの投稿は、私がここまで到達するのに役立ちました:

• Visual C++ プリコンパイル済みヘッダー エラー
• プリコンパイル済みヘッダー

リリースモードでビルドすると、すべて問題ありません。ただし、デバッグモードでビルドしようとすると、次のようなエラーが大量に発生します。

エラー 1 エラー C2859: [削除済み]\debug\vc100.idb は、このプリコンパイル済みヘッダーの作成時に使用された IDB ファイルではありません。プリコンパイル済みヘッダーを再作成してください。

この .idb ファイルは、Visual Studio によって作成された中間デバッグ ファイルだと思います。

このエラーが発生するのはなぜですか? つまり、プリコンパイル済みヘッダーを作成するときに、この .idb ファイルを使用しなかったのはなぜでしょうか?

回答を得るために、どのような情報が必要なのかわかりません。他に提供する必要がある情報があるかどうかを尋ねてください。

マルチアーキテクチャビルドのプロジェクトでGCCプリコンパイル済みヘッダーを使用していますが、現在のソースのディレクトリとは異なるディレクトリに配置しようとすると、問題が発生します。

ファイルは二重引用符で囲まれており、山かっこに変更すると機能しますが、問題は、同じプリコンパイル済みヘッダー名を使用するプロジェクトが他にもたくさんあるため、すべてを山かっこに変更することは望ましくないことです。同じファイルのVisualStudioビルドに含めるヘッダーがあいまいになる可能性があるためです。

GCCは、現在のディレクトリで、検索パスの前にある二重引用符のインクルードを検索します。-I-オプション（例）を使用して回避できる-Ipch_dir.i686 -I-ため、プリコンパイル済みヘッダーディレクトリが現在のディレクトリの前に検索されますが、このオプションは非推奨です。GCCは-iquote、を使用することを提案していますが、と同じ効果はありません-I-。

したがって、問題は、すべてのプリコンパイル済みヘッダーに山かっこへのディレクティブを含めたり、非推奨のGCCスイッチを使用したりせずに、どうすれば機能させることができるかということです。

私は単純な問題にぶつかったようです。コンパイル済みの Web サイトをホストしています。私のローカルボックスでコンパイルして正常に動作します。しかし、IIS でホストすると、次のエラーで失敗します。

タイプ「MyHero.Home1」を読み込めませんでした。

Bin で MyHero.dll を見つけることができます。これもオブジェクト ブラウザで開いたところ、Home1 というタイプがあることがわかります。MyHero.Home1 タイプが存在し、公開されています。したがって、確実にプリコンパイルされています。ここで何が欠けているのかわかりません。これは、VB.NET での初めての冒険です。

コードビハインドはこんな感じ

部分クラスの他の部分は、デザイナーによって生成されます。そしてHome.aspx.designer.vbにあります

プリコンパイルされたサイトであるため、コードビハインドをアップロードしていません。

Windows サーバー 2003 で IIS を使用しています。

Home1 が表示されます。オブジェクト エクスプローラーの MyHero Namespace の下に表示されます。クラスHome1の周りに名前空間Heroを追加したことを確認するために、試してみましたが同じ結果になりました。また、aspxページの継承から名前空間プレフィックスを削除しようとしましたが、役に立ちませんでした。

Windows Server 2003 上の IIS に関する既知の問題はありますか? .NET Framework と IIS のインストール順序はこれに影響しますか? これを新しくインストールしたボックスでホストしています。私の開発ボックスでは問題なく動作します。

dariom のおかげで、Fusion Log Viewer をインストールできました。これがバインディングログです。あまり手がかりがないようです。そうですか？

大きな（12 mb）Prefix.pch.gchファイルが最終的なiPhoneアプリケーションにコピーされています。プロジェクトには存在せず、ビルドログにのみ表示されます。それ以外の点では小さなアプリケーションサイズにかなりの追加があります。xcodeによるコピーを停止するための提案はありますか？誰かがそれが何であるか知っていますか？少し調べてみたところ、プリコンパイル済みヘッダーのキャッシュファイルのように見えましたが、なぜ12MBなのかはわかりませんでした。

XCodeは、プロジェクトをビルドするたびにすべてのソースをコンパイルし、多くの時間がかかります。プリコンパイル済みヘッダーが機能しないようです。プロジェクトの場所を変更する前は正しく機能していました。それを機能させるために私は何をしますか？

UPD：数分前に修正されました。方法がわかりません。

UPD2：また始まります！XCodeは、ビルドするたびにすべてのソースをコンパイルします。この問題を管理する方法は？

私はxcodeが初めてで、何かが欠けているに違いありません。

新しいコマンド ライン プロジェクトを作成します。tempprog と呼びます (たとえば)。
プロジェクト/プロジェクト設定の編集を選択します。
プレフィックス ヘッダー (tempprog_Prefixz.pch) の名前を編集します。
ビルド - もちろん、tempprog_Prefixz.pch を探して失敗し
ます。ここで、プレフィックス ヘッダーの名前を tempprog_Prefix.pch に戻します。
再度ビルドします。動作するはずですが、動作しません。まだtempprog_Prefixz.pchを探しています

クリーニングしても状況は改善されません。ここで何が欠けていますか？Prefixz.pch の名前はどこに保持されていますか? ProcessPCH コマンドのビルド出力を見ると、まだ Prefixz を使用しようとしていることがわかります。

プロジェクト内のすべてのソースファイルで使用されるプリコンパイル済みヘッダーstdafx.hがあります。したがって、stdafx.hのすべてのヘッダーは、プロジェクトのすべてのコードファイルで使用できます。

私が確信していないのは、プリコンパイル済みヘッダーにすでに含まれているものを再含めるかどうかです。皆さんはどう思いますか？

例えば

stdafx.h

my_class.h

main.cpp

プロジェクトの再構築を実行する必要がある場合もありますが、そのたびにプリコンパイル済みヘッダーを再コンパイルしたくありません。少なくともこの場合は、目的が損なわれます。PCHを再コンパイルせずにVisualStudioを再構築し、必要に応じてPCHをコンパイルする方法はありますか（めったに変更されないヘッダーが変更された場合）

Xcode を使用して「C++ 標準動的」ライブラリ プロジェクトを作成し、LLVM 2.0 を使用してコンパイルしました。PCH ファイルには次の行#include <iostream>が含まれていますが、ファイルTest.cpにもその#include <iostream>ステートメントが含まれています。

奇妙なことに、Test.cpSemantic Issue – Use of undeclared identifier 'std'のステートメントを削除すると、そのステートメントが PCH にも含まれているにもかかわらず、ビルドがエラーで失敗します。

PCH が機能しないのはなぜですか? 不足している設定はありますか？私は以前にそれらを使ったことは一度もありませんでした (それらは常に機能するため)。そのため、まったく新しいプロジェクトであっても、何が原因で機能しないのかわかりません。

いくつかのプロジェクトで使用されているフレームワークがあります (フレームワークがどのように機能するかを示すいくつかのサンプルが含まれています)。フレームワークには、コア、グラフィック、物理、GUI などのコンポーネントがあります。それぞれが個別のライブラリです。構成もいくつかあります。

メイン ソリューション ファイルは、プロジェクトがライブラリを使用できるように、可能なすべての構成で完全なプロジェクトをコンパイルします。フレームワークは、特にフレームワークを利用するプロジェクトに取り組んでいる誰か (私を含む) によって再コンパイルされることはめったにないため、多くのヘッダーをプリコンパイルすることは理にかなっています。

最初は、各プロジェクト/サンプルに、プロジェクト全体で使用される独自のプリコンパイル済みヘッダーを用意しました。毎回同じ pch (たとえば、デバッグ) を再構築する必要があるため、共有 PCH によって冗長な PCH コンパイルが削減されると判断しました。ここまでは順調ですね。ライブラリと一緒に PCH をコンパイルするプロジェクトがあります。以降のすべてのプロジェクト/サンプルは現在、同じ PCH を使用しています。これは素晴らしく機能しました。

唯一の問題は、ファイル サイズが大きくなったことです。フレームワークを使用するプロジェクトがリリースされることを意図しているかのように、これは障害ではありません。共有 PCH から切り離され、独自のプロジェクトが作成される可能性があります。私は迅速な開発のためにこれを行いました (ビルドの準備ができている新しいプロジェクト/サンプルの VS プロジェクト ファイルとソース ファイルを作成し、古いプロジェクトを使用していた以前のプロジェクトのアップグレードを容易にするツールを実際に作成しました)。フレームワークのバージョン)。

とにかく、ファイル サイズの増加は、共有 PCH を作成している独立した VS プロジェクト ファイルに、すべてのライブラリのすべてのヘッダーが含まれているためです。私の質問は、条件付きコンパイル (#ifndef) を使用して最終的な実行可能ファイルのサイズを縮小できるかどうかです。または、複数の PCH ファイルを何らかの方法で共有することもできます (私の知る限り、それは不可能ですが、間違っている可能性があります)。私の PCH ファイルに関する知識は非常に限られているため、意味が分からない場合は、そう言ってください (優しい言葉で:))。 .

ありがとう！

注: 繰り返して明確にするために、これまでのところ、共有 PCH を含むすべてのライブラリをコンパイルする 1 つのソリューション ファイルがあります。すべてのサンプルとプロジェクトを再コンパイルすると、せいぜい数秒かそれ以上でコンパイルされます。以前は、各プロジェクトで PCH ファイルが再作成されていました。また、最初はライブラリごとに PCH が必要でしたが、ソース ファイルで複数の PCH ファイルを使用できないことがわかったため、このオプションは実行できませんでした。もう 1 つのオプションは、PCH ファイルのすべての可能な組み合わせをコンパイルすることですが、これは時間がかかり、面倒で、エラーが発生しやすくなります。