MENU

C1010 / C1853 エラーの直し方：PCH 設定の修正手順【Visual Studio】

ビルド
【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.cppのプロパティ ページで、プリコンパイル済みヘッダーが「作成 (/Yc)」、ヘッダー ファイルがpch.hに設定されている画面

ここで重要なのは、「プロジェクト全体では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. プリコンパイル済みヘッダー を 使用しない に変更する
third_party_cpp.cppのプロパティで「プリコンパイル済みヘッダーを使用しない」に変更している画面

.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のプロパティ ページで、プリコンパイル済みヘッダーが「プリコンパイル済みヘッダーを使用しない」に設定されている画面

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

// 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の前提とファイルごとの設定が一致しているかを確認してください。

ビルド

関連記事

目次