我看到很多代码包括stdafx.h。假设我不想使用预编译头文件,并且我将会手动包含所有所需的系统头文件。在这种情况下,是否还有其他好的原因需要使用stdafx.h
?
我看到很多代码包括stdafx.h。假设我不想使用预编译头文件,并且我将会手动包含所有所需的系统头文件。在这种情况下,是否还有其他好的原因需要使用stdafx.h
?
如果您不想使用预编译头文件,那么使用标准的包含文件就没有意义了 - 这会使每个包含它的文件的构建变慢,并导致它们包含不需要的额外内容。摆脱它,只包含它们需要的头文件。
stdafx.h
是另一个头文件。如果你觉得不需要它,可以随意不包含它并将其从项目中删除。
但是通常会有类似于stdafx.h的文件,专门用于预编译头文件的工作,并且不需要在每个源文件中手动包含所有内容。
您可以使用预编译头文件(这是好事情)而不使用stdafx.h(我也讨厌它)。 我只能访问VC ++ 6.0,但在那里,转到“项目设置| C / C ++ |预编译标头”,选择“自动使用预编译标头”,但保留“通过编译”框为空。
即使没有预编译头文件,stdafx.h 也可以作为一个实用工具,将所有文件共有的头文件包含和定义分组。
当然,你可以选择在每个文件中重复所有这些定义。但是,stdafx.h 并非必需品。
正如其他人所提到的那样:如果您不需要预编译头文件,那么您实际上不需要stdafx.h。实际上,仅仅使用它来分组常用包含项是相当糟糕的做法。
事实上,即使在使用预编译头文件的情况下,最好也要在stdafx.h(或precompiled.h或任何您想要称呼它的东西)之后包含您的进程实际需要的头文件,并在预编译头文件中使用#ifdef魔法来关闭PCH的使用。
为什么?为了检查您的模块依赖关系。能够禁用PCH使您能够捕获您是否包含必要的模块,然后您可以编写一个工具通过解析您的.cpp和.h文件(当然不包括PCH头文件)来检查您的模块互操作性。
我知道这是一个旧的帖子,但我想把我的意见传达给读者。我在2017年发现了这个问题,所以我相信我不是唯一一个会来这里的人。
使用预编译头文件有一个优点,可能被其他人忽视,因为他们已经使用自己的做法很多年了。C++标准已经发展得非常好了。你可以使用PCH文件来代替在20个文件中包含vector和iostream等内容,这样编译器需要做的工作就少了,这对每个人都是好事。此外,你还可以将常用的宏放在其中,例如VERIFY、ASSERT和智能类对象。不要将你的类头文件放在里面,因为那样做没有意义,而是放置标准库或者你需要在许多地方全局使用的东西,比如我提到的宏。
基本上,你需要在每个文件中包含所需的头文件,比如iostream、string和vector,这样你就可以有效地将其编译为文件的内联部分。如果你包含一个“预编译”头文件,那么仅仅是名称就应该让你明白了。