Visual Studio 中的“stdafx.h”是做啥用的？

Posted 2023-02-25

【中文标题】Visual Studio 中的“stdafx.h”是做啥用的？

【英文标题】：What is "stdafx.h" used for in Visual Studio?Visual Studio 中的“stdafx.h”是做什么用的？

【发布时间】：2011-06-11 04:49:58

【问题描述】：

我在 Visual Studio 2010 中启动项目时会自动生成一个名为 stdafx.h 的文件。我需要制作一个跨平台的 C++ 库，所以我不/不能使用这个头文件。

stdafx.h 是做什么用的？我把这个头文件去掉可以吗？

【问题讨论】：

如果我得到与 stdafx.h 相关的编译错误，我通常将设置设置为不创建或使用此文件..

文章：StdAfx.h for Novices - viva64.com/en/b/0265

你可以在其他平台上正常使用头文件，对他们来说只是一个普通的头文件。它只是在那里没有提供任何性能优势。

【参考方案1】：

所有 C++ 编译器都有一个严重的性能问题需要处理。编译 C++ 代码是一个漫长而缓慢的过程。

编译包含在 C++ 文件之上的头文件是一个非常漫长而缓慢的过程。编译构成 Windows API 和其他大型 API 库一部分的巨大标头结构是一个非常、非常漫长而缓慢的过程。必须为每个 Cpp 源文件一遍又一遍地做这件事是丧钟。

这不是 Windows 独有的，而是所有必须针对 Windows 等大型 API 进行编译的编译器都面临的老问题。

Microsoft 编译器可以通过一个名为预编译头文件 的简单技巧来改善这个问题。诀窍非常巧妙：尽管每个 CPP 文件都可能合法地为每个 Cpp 文件顶部包含的头文件链赋予略微不同的含义（通过在包含之前使用不同的宏#define'd 之类的东西，或者通过以不同的顺序包含标题），通常情况并非如此。大多数时候，我们有几十个或几百个包含文件，但它们都旨在对您的应用程序中正在编译的所有 Cpp 文件具有相同的含义。

如果编译器不必每次都从头开始编译每个 Cpp 文件以及几十个包含文件，那么它可以节省大量时间。

诀窍在于指定一个特殊的头文件作为所有编译链的起点，即所谓的“预编译头”文件，由于历史原因，它通常是一个名为 stdafx.h 的文件.

只需按适当的顺序在 stdafx.h 文件中列出 API 的所有大型标头，然后在任何有意义的内容之前以 #include "stdafx.h" 开头每个 CPP 文件（大约之前唯一允许的是 cmets)。

在这些条件下，编译器不会从头开始，而是从 stdafx.h 中所有内容的已保存结果开始编译。

我不相信这个技巧是微软编译器独有的，我也不认为这是一个原创的开发。

对于 Microsoft 编译器，控制预编译头文件使用的设置由编译器的命令行参数控制：/Yu "stdafx.h"。可以想象，stdafx.h 文件名的使用只是一种约定；如果您愿意，可以更改名称。

在 Visual Studio 2010 中，此设置由 GUI 控制，方法是右键单击 CPP 项目，选择“属性”并导航到“配置属性\C/C++\预编译头文件”。对于其他版本的 Visual Studio，GUI 中的位置会有所不同。

请注意，如果您禁用预编译头文件（或通过不支持它们的工具运行您的项目），它不会使您的程序非法；它只是意味着您的工具每次都会从头开始编译所有内容。

如果您正在创建一个没有 Windows 依赖项的库，您可以轻松地从 stdafx.h 文件中注释掉或删除 #includes。不需要删除文件本身，但显然您也可以这样做，方法是禁用上面的预编译头设置。

【讨论】：

即使您只用于 std 命名空间中的文件，您也可以获得速度优势

omg ，确实非常好的答案。我正在寻找符合标准的 c 编译器。事实证明，我可以从项目属性中禁用 micro$oft 扩展，将编译器从“auto”更改为“c”，并且您几乎拥有“标准”编译器和 IDE。

@Rishi: 'line' 是指#include "stdafx.h" 吗？当然，但这只是一个标准的#include。 “MS 扩展”部分只是编译器性能优化；它不会改变恰好称为“stdafx.h”的头文件的语义。请注意，如果您删除包含并且您的代码依赖于通过 stdafx.h 包含的任何内容，您将不得不直接包含它。

@Youda008，不太正确。在编译代码文件之前，头文件的内容会简单地直接“粘贴”在源文件中#include 它们的位置（由评估宏的相同“预处理器”步骤完成）。然后将生成的总文件传递给实际的编译器，它永远不会将头文件视为单独的实体。您只在头文件上放置声明，因为这在头文件上效果很好 - 这是一个常规规则。试试吧！创建一个包含整个程序的头文件，然后创建一个只有#include 的源文件。它编译得很好。

历史好奇心。 stdafx.h 的名称可以追溯到 1992 年左右，当时 MFC 在发布之前被称为“应用程序框架扩展”。 Visual Studio 2015 仍默认名称为 ..

【参考方案2】：

这是一个“预编译的头文件”——您在 stdafx.h 中包含的任何头文件都经过预处理，以节省后续编译的时间。你可以阅读更多关于它的信息here on MSDN。

如果您正在构建跨平台应用程序，请在创建项目时选中“空项目”，Visual Studio 根本不会在您的项目中放置任何文件。

【讨论】：

此文件中没有任何内容不适用于其他平台。如果编译器不支持预编译头文件，它可能会减慢那里的编译速度，但它不应该破坏它。它只是一个包含其他头文件的头文件。

@detunized：也许我的回答听起来不是这样，所以感谢您澄清这部分。

【参考方案3】：

“Stdafx.h”是一个预编译的头文件。它包含标准系统包含文件和项目特定的包含文件，这些文件经常使用但不经常更改。这减少了编译时间和不必要的处理。

Precompiled Header stdafx.h 基本上用在 Microsoft Visual Studio 中，让编译器知道已经编译过的文件，而无需从头开始编译。 您可以阅读更多相关信息

http://www.cplusplus.com/articles/1TUq5Di1/

https://docs.microsoft.com/en-us/cpp/ide/precompiled-header-files?view=vs-2017

【参考方案4】：

定义：“Stdafx.h”是一个预编译的头文件。

预编译意味着编译一次就不需要再编译了。 stdafx.h 基本用在

Microsoft Visual Studio

让编译器知道文件已编译一次，并且 无需从头开始编译。

例如： 如果您包含以下 windows 头文件。

代码：

#include <windows.h>
#include <string.h>

int main()

 //your code
return 0;

编译器总是从头开始编译这些头文件。 但如果您在这些标头之前包含#include "stdafx.h"，那么 编译器将从 stdafx.h 中找到已编译的头文件并执行 不要从头开始编译。 编译器第一次正常从头开始编译。

代码：

#include "stdafx.h"
#include <windows.h>
#include <string.h>

int main()

//your code
 return 0;

优点：

减少编译时间。 减少不必要的处理。

来源：http://www.cplusplus.com/articles/1TUq5Di1/

【参考方案5】：

我自己也遇到了这个问题，因为我试图为自己创建一个简单的框架，但首先是在 Visual Studio 2017 中创建一个新的 Win32 程序选项。“stdafx.h”是不必要的，应该删除。然后，您可以删除解决方案资源管理器中的愚蠢的“stdafx.h”和“stdafx.cpp”以及项目中的文件。在它的地方，你需要放

#include <Windows.h>

改为。