的#pragma一次对战＃如果定义MYHEADER_INCLUDED_

Question

可能重复：
#pragma once vs include guards?

什么是使用#pragma once和#if !defined MYHEADER_INCLUDED_结构的差异（在性能，可用性和功能性）？或者两者有什么不同？

Answer 1

维基百科有此所有的答案，是很容易找到

From the article

在C和C++编程语言，#pragma once是非标准 但广泛支持的预处理指令旨在导致当前源文件仅在单个编译中包含一次。

因此，#pragma once服务于相同的目的#include警卫，但与 几个优点，包括：不代码，避免名称冲突，和 改进的编译速度。

它更深入地看待了article的优缺点。如果你真的感兴趣，我建议你完全阅读它，而不只是上面的blurb。

Answer 2

1. 性能 - 通常是#pragma once执行编译速度更快，因为它的意图是明确的
2. 功能 - 无论是用于同一目的 - 避免一个头文件的一个以上的夹杂物。该defined版本当然有更广泛的使用了过多的，如果用小心翼翼的将允许其他文件中查看前被列入（例如用于条件编译）
3. 可用性 - 如果便携性是不是一个问题去#pragma once - 然而，这是一个非标准扩展

Answer 3

正如Dan McG说，他们几乎是相同的。但是我不推荐使用#pragma，除非在不能避免的情况下（比如#pragma部分）。它只会让代码更加不标准。

而且没有功能/性能问题。因为这是在编译时间。它可能增加编译时间，但我没有经历任何区别！

Answer 4

虽然编译指令在很多方面都优于#ifdef警卫，但它有一个主要缺陷：它基于文件系统路径：它使用两个不同（绝对）路径也是两个不同文件的基本假设。不幸的是，这并非总是如此。

虽然不太可能会遇到问题，但需要注意。

Answer 5

就性能而言，我还没有对它进行测量，但有广泛报道，编译器认识到#include后卫成语，并且不重新打开/重新处理使用它的文件（因此将它们当作使用#pragma once来对待） 。

除了潜在的性能优势（可能不存在）之外，我几乎没有看到#pragma once提供的功能 - 当您创建新的头文件时它更方便 - 但是看守的确不是那么繁重。由于#pragma once不是特别引人注目，因为我偶尔还会遇到不支持它的编译器，所以我使用了警卫。

如果显示#pragma once有显着的性能影响，我肯定会开始使用它。

这就是说 - 我希望C被定义为只包含头一次 - 除非某个机制被调用来指示头每次被包含时应该被处理。当你想要这种行为的时代远远超出你不想要的时代（而且我还会偶尔遇到没有警卫或者没有看守的标题）。但它并没有定义的方式，因此包括守卫它是...

Answer 6

一些更多的背景这个：

• Experiments with includes - 发现，曾经的#pragma比更快包括在Visual Studio 2003/2005
• Even more experiments with includes - 对不同类型的案例进行更多调查，如果您要减少构建时间，那么可以使用非常有趣的系列。

Answer 7

#pragma once是非标准的。

如果您很满意在您尝试将其移植到不同平台时发现应用程序或库不会构建时，更改每个头文件的前景，那么这可能是一个不错的选择。

否则，坚持#ifndef/#define/#endif。 特别是如果您正在为其他人使用建立库代码。