【MFC】C1010 / C1853 エラーの直し方：PCH（プリコンパイル済みヘッダー）設定の修正手順

MFC プロジェクトに外部の .cpp や .c を追加した瞬間、fatal error C1010 や fatal error C1853 が急に出ることがあります。検索では単に C1010、C1853 だけで調べられることも多い典型エラーです。

fatal error C1010: プリコンパイル ヘッダーを検索中に不明な EOF が見つかりました。'#include "pch.h"' をソースに追加しましたか?

fatal error C1853: 'Debug\\MyApp.pch' プリコンパイル済みヘッダー ファイルは別のバージョンのコンパイラからのものです。または、C++ のプリコンパイル済みヘッダーを C で使用しています (その逆も考えられます)

結論から言うと、この 2 つはどちらも、PCH（プリコンパイル済みヘッダー）の設定とファイルごとの実態がずれているときに起きます。stdafx.h 時代のプロジェクトでも、近年の pch.h プロジェクトでも原因の構造は変わりません。

症状	原因	最短の対処
C1010	そのファイルだけ /Yu なのに pch.h / stdafx.h を先頭で読んでいない	自前コードならヘッダーを先頭に追加。外部コードならそのファイルだけ PCH を使用しない
C1853	古い .pch が残っている、または .c / /TC が C++ 用 PCH を使おうとしている	まず クリーン → リビルド。.c が原因ならそのファイルだけ PCH の対象から外す

先に見分け方だけ書くと、C1010 は「/Yu のまま pch.h / stdafx.h を読んでいない」ケース、C1853 は「古い .pch か、.c が C++ 用 PCH を使っている」ケース をまず疑います。この記事では、その切り分け方と最小の修正手順を順番に整理します。

C1010 / C1853 の原因チェックリスト

1. C1010 が出ているなら、そのファイルが /Yu のまま pch.h / stdafx.h を先頭で読んでいない可能性を先に見る
2. C1853 が出ているなら、最初に クリーン → リビルド を試して古い .pch を疑う
3. C1853 が .c や /TC のファイルで出ているなら、そのファイルだけ PCH の対象から外す設定になっているか確認する

まずこの 3 点で当たりを付けると、C1010 と C1853 の切り分けがかなり速くなります。

---

PCH の前提: 全ファイル共通ルールではない

PCH（Precompiled Header）は、巨大なヘッダー群を毎回パースし直さないための高速化機構です。MFC では afxwin.h などの重量級ヘッダーを毎回読むとビルドが重くなるため、通常は以下の形になっています。

1. pch.cpp または stdafx.cpp が pch.h / stdafx.h から .pch を作る（/Yc）。
2. 他の .cpp はその .pch を使う（/Yu）。
3. ただし、外部から持ち込んだ純粋な .cpp や .c は、この前提に沿わないことがある。

ここで重要なのは、「プロジェクト全体では PCH を使うが、特定ファイルだけ例外にできる」 という点です。C1010/C1853 は、この例外設定を入れるべきファイルに、全体ルールをそのまま押し付けたときに起きやすいエラーです。

---

C1010 の正体: /Yu のままなのに pch.h を読んでいない

C1010 は、そのファイルが PCH を使う設定なのに、先頭で対応ヘッダーを読んでいない ときに出ます。典型例は、外部からコピーした sha256.cpp や json_reader.cpp を MFC プロジェクトに追加したケースです。

// third_party_cpp.cpp
int ThirdPartyCpp()
{
    return 7;
}

このファイルは単体では何も悪くありません。しかしプロジェクト側が /Yu"pch.h" なら、コンパイラは「最初に #include "pch.h" が来るはずだ」と期待します。そこで EOF まで探して見つからないと C1010 になります。

対処 1: 自分で管理する cpp なら先頭に pch.h を入れる

そのファイルがプロジェクト内の通常コードで、MFC 側のヘッダーも参照して問題ないなら、単純に先頭へ追加すれば直ります。

#include "pch.h"

int MyFeature()
{
    return 42;
}

旧プロジェクトでは pch.h ではなく stdafx.h です。名前が違うだけで判断基準は同じです。

対処 2: 外部ライブラリの cpp なら、そのファイルだけ PCH を切る

こちらが本命です。サードパーティーのソースに pch.h を書き足すと、アップデート時に差分管理が崩れます。外部コードは汚さず、そのファイルだけ「プリコンパイル済みヘッダーを使用しない」 にするのが安全です。

1. ソリューション エクスプローラーで対象の .cpp を右クリックし、プロパティ を開く
2. C/C++ ＞ プリコンパイル済みヘッダー を選ぶ
3. プリコンパイル済みヘッダー を 使用しない に変更する

.vcxproj では次の設定に相当します。

<ClCompile Include="third_party_cpp.cpp">
  <PrecompiledHeader>NotUsing</PrecompiledHeader>
</ClCompile>

この方法なら、プロジェクト全体のビルド速度は維持したまま、例外ファイルだけ素通しでコンパイルできます。

---

C1853 の正体 1: 古い .pch が残っている

C1853 は「C から C++ の PCH を使った」場合だけでなく、今ある .pch が現在のコンパイラや設定と食い違っているときにも出ます。Visual Studio の更新直後や、ツールセット変更後、ブランチ切り替え後に起きやすいパターンです。

1. まず ビルド ＞ クリーン を実行する
2. 続けて リビルド を実行する
3. それでも直らない場合は、エラーメッセージに出ているファイルが .c か、ファイル単位で /TC になっていないか確認する

この 3 手で直るなら、原因は「古い中間生成物」です。ここで深追いしてコードを触る必要はありません。

---

C1853 の正体 2: .c ファイルが C++ 用 PCH を使おうとしている

クリーン後も C1853 が残り、問題のファイルが .c ならこちらです。MFC プロジェクトの PCH は通常 C++ として作られているため、C ソースからそのまま使うことはできません。

// legacy_c_module_broken.c
#include "pch.h"

int LegacyCModuleBroken(void)
{
    return 0;
}

この状態で .c をビルドすると、「C++ のプリコンパイル済みヘッダーが C から使用されています」という C1853 になります。

推奨対処: .c は .c のままにして、そのファイルだけ PCH を切る

外部 C ライブラリを取り込んだだけなら、無理に C++ 化しない方が安全です。.c 側から pch.h / stdafx.h を外し、さらに そのファイルだけ「プリコンパイル済みヘッダーを使用しない」 にします。

修正後のイメージはこうです。

// legacy_c_module_fixed.c
int LegacyCModuleFixed(void)
{
    return 0;
}

どうしてもそのファイルを C++ として扱いたいなら、ファイルのプロパティで コンパイル言語の選択 を C++ コードとしてコンパイル (/TP) に変える方法もあります。ただし、C ライブラリの文法差分で別エラーが増えやすいので、最初の選択肢にはしない方が無難です。

---

迷ったときの判定フロー

• C1010 が出たら、そのファイルの先頭に pch.h / stdafx.h があるかを見る
• 外部コードなら、まずそのファイルだけ PCH の対象から外して試す
• C1853 が出たら、最初に クリーン → リビルド で古い .pch を疑う
• まだ直らず問題のファイルが .c なら、pch.h を読ませず、そのファイルだけ PCH を切る
• /TP での C++ 強制は最終手段にする

PCH はプロジェクト全体で一律に使うものではなく、外部コードなど前提に合わないファイルだけ個別に対象から外せます。この点を押さえておくと、MFC プロジェクトでも外部コードを無理なく共存させられます。C1010 と C1853 が出たら、まず PCH の前提とファイルごとの設定が一致しているかを確認してください。