关于“fatal error C1083: Cannot open include file: 'StdAfx.h': No such file or directory”的问题

在添加别人的工程源文件时，遇到 “fatal error C1083: Cannot open include file: 'StdAfx.h': No such file or directory” 的错误，有网友给出这样的解决方法：

1、“把所有的"#include <StdAfx.H>"替换成#include <stdafx.h>就可以了”

2、“就是说你的VC里面没有'stdafx.h'这个文件，或者打开这个文件异常，我估计第一种情况可能性较大，与编译器有关，我以前也出现过类似情况，后来重新下载了一个编译器”

3、“用VC当然不能这样,你用VC7.0编译就可以了”

。。。。。。

先不说以上的对不对，我先把我的解决方式说一下。

打开 <stdafx.h>文件能够看到如下定义：

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

关于 _MSC_VER >1000，查阅MSDN，解释如下：

Evaluates to the major and minor number components of the compiler's version number. The major number is the first component of the period-delimited version number and the minor number is the second component.

For example, if the version number of the Visual C++ compiler is 17.00.51106.1, the _MSC_VER macro evaluates to 1700.

也就是说，这是编译器的一个版本号，如编译器的版本在10.00.以下，就不支持#pragma once 。

#pragma once 在<stdafx.h>中的意思是，如果工程包含了多个<stdafx.h>，那么编译器只会编译其中一个。

这就是出现这个问题（如题）的其中一个原因，必须保证自己的工程只包含一个<stdafx.h>，如果多了的话，编译器报告出错。

所以遇到了“fatal error C1083: Cannot open include file: 'StdAfx.h': No such file or directory” 的问题时，首先要检查是否在其他文件中也包含了<stdafx.h>。

补充关于#pragma once 的MSDN：

Specifies that the file will be included (opened) only once by the compiler when compiling a source code file.

Syntax

#pragma once

Remarks

The use of #pragma once can reduce build times as the compiler will not open and read the file after the first #include of the file in the translation unit. This is referred to as multiple-include optimization. It has an effect similar to the #include guard idiom, which uses preprocessor macro definitions to prevent multiple inclusion of the contents of the file. This also helps to prevent violations of the one definition rule—the requirement that all templates, types, functions, and objects have no more than one definition in your code.

For example:

// header.h
#pragma once
// Code placed here is included only once per translation unit

We recommend the #pragma once directive for new code because it doesn't pollute the global namespace with a preprocessor symbol. It requires less typing, is less distracting, and can't cause symbol collisions—errors caused when different header files use the same preprocessor symbol as the guard value. It is not part of the C++ Standard, but it is implemented portably by several common compilers.

There is no advantage to use of both the #include guard idiom and #pragma once in the same file. The compiler recognizes the #include guard idiom and implements the multiple include optimization the same way as the#pragma once directive if no non-comment code or preprocessor directive comes before or after the standard form of the idiom:

// header.h
// Demonstration of the #include guard idiom.
// Note that the defined symbol can be arbitrary.
#ifndef HEADER_H_     // equivalently, #if !defined HEADER_H_
#define HEADER_H_
// Code placed here is included only once per translation unit
#endif // HEADER_H_

We recommend the #include guard idiom when code must be portable to compilers that do not implement the#pragma once directive, to maintain consistency with existing code, or when the multiple-include optimization is impossible. This can occur in complex projects when file system aliasing or aliased include paths prevent the compiler from identifying identical include files by canonical path.

Be careful not to use #pragma once or the #include guard idiom in header files that are designed to be included multiple times, using preprocessor symbols to control their effects. For an example of this design, see the <assert.h> header file. Also be careful to manage include paths to avoid creating multiple paths to included files, which can defeat the multiple-include optimization for both #include guards and #pragma once.