#pragma一次vs包括守卫吗？ [重复]

本文翻译自：#pragma once vs include guards? [duplicate]

This question already has answers here : 这个问题已经在这里有了答案 ：

Is #pragma once a safe include guard? #pragma是否曾经是安全的门卫？ (14 answers) （14个回答）

Closed 2 months ago . 2个月前关闭。

I'm working on a codebase that is known to only run on windows and be compiled under Visual Studio (it integrates tightly with excel so it's not going anywhere). 我正在开发一个仅在Windows上运行并在Visual Studio下进行编译的代码库（它与excel紧密集成，因此不会在任何地方使用）。 I'm wondering if I should go with the traditional include guards or use #pragma once for our code. 我想知道我是否应该使用传统的包含卫兵或将#pragma once用于我们的代码#pragma once 。 I would think letting the compiler deal with #pragma once will yield faster compiles and is less error prone when copying and pasting. 我认为让编译器#pragma once处理#pragma once会产生更快的编译，并且在复制和粘贴时不太容易出错。 It is also slightly less ugly ;) 它也不太丑;)

Note: to get the faster compile times we could use Redundant Include Guards but that adds a tight coupling between the included file and the including file. 注意：为了获得更快的编译时间，我们可以使用冗余包含保护，但这在包含文件和包含文件之间增加了紧密的联系。 Usually it's ok because the guard should be based on the file name and would only change if you needed to change in the include name anyways. 通常没关系，因为保护措施应基于文件名，并且仅在需要更改包含名称时才会更改。

---

#1楼

参考：https://stackoom.com/question/4naa/pragma一次vs包括守卫吗-重复

---

#2楼

I don't think it will make a significant difference in compile time but #pragma once is very well supported across compilers but not actually part of the standard. 我认为这不会对编译时间产生重大影响，但是#pragma once在各个编译器中得到很好的支持，但实际上并不是标准的一部分。 The preprocessor may be a little faster with it as it is more simple to understand your exact intent. 预处理器可能会更快一点，因为它更容易理解您的确切意图。

#pragma once is less prone to making mistakes and it is less code to type. #pragma once不太容易出错，而且键入的代码也更少。

To speed up compile time more just forward declare instead of including in .h files when you can. 为了加快编译时间，只要可以，就直接声明而不是包含在.h文件中。

I prefer to use #pragma once . 我更喜欢#pragma once使用#pragma once 。

See this wikipedia article about the possibility of using both . 有关使用这两种方法的可能性，请参阅此Wikipedia文章 。

---

#3楼

If you're positive that you will never use this code in a compiler that doesn't support it (Windows/VS, GCC, and Clang are examples of compilers that do support it), then you can certainly use #pragma once without worries. 如果你是积极的，你永远不会在一个编译器使用此代码不支持它（在Windows / VS，GCC，以及锵是指那些支持它的编译器的例子），那么你当然可以使用#pragma一次无后顾之忧。

You can also just use both (see example below), so that you get portability and compilation speedup on compatible systems 您也可以同时使用两者（请参见下面的示例），以便在兼容系统上获得可移植性和编译速度的提高

#pragma once
#ifndef _HEADER_H_
#define _HEADER_H_

...

#endif

---

#4楼

#pragma once allows the compiler to skip the file completely when it occurs again - instead of parsing the file until it reaches the #include guards. #pragma once允许编译器在文件再次出现时完全跳过文件-而不是解析文件直到到达#include防护。

As such, the semantics are a little different, but they are identical if they are used they way they are intended to be used. 因此，语义有些不同，但是如果使用它们，则它们是相同的，如果要使用它们，则它们是相同的。

Combining both is probably the safest route to go, as in the worst case (a compiler flagging unknown pragmas as actual errors, not just warnings) you would just to have to remove the #pragma's themselves. 结合使用这两种方法可能是最安全的方法，因为在最坏的情况下（编译器将未知的实用程序标记为实际错误，而不仅仅是警告），您只需要删除#pragma本身即可。

When you limit your platforms to, say "mainstream compilers on the desktop", you could safely omit the #include guards, but I feel uneasy on that, too. 当您将平台限制为“台式机上的主流编译器”时，可以安全地省略#include防护，但是对此我也感到不安。

OT: if you have other tips/experiences to share on speeding up builds, I'd be curious. OT：如果您还有其他技巧/经验可以分享，以加快构建速度，我会很好奇。

---

#5楼

Until the day #pragma once becomes standard (that's not currently a priority for the future standards), I suggest you use it AND use guards, this way: 直到#pragma once成为标准的一天（当前尚未成为将来的标准的优先事项）之前，我建议您使用它并使用防护措施，方法如下：

#ifndef BLAH_H
#define BLAH_H
#pragma once

// ...

#endif

The reasons are : 原因如下：

• #pragma once is not standard, so it is possible that some compiler don't provide the functionality. #pragma once不是标准的，因此某些编译器可能不提供该功能。 That said, all major compiler supports it. 也就是说，所有主要的编译器都支持它。 If a compiler don't know it, at least it will be ignored. 如果编译器不知道，至少它将被忽略。
• As there is no standard behavior for #pragma once , you shouldn't assume that the behavior will be the same on all compiler. 由于#pragma once没有标准行为，因此您不应假定所有编译器的行为都相同。 The guards will ensure at least that the basic assumption is the same for all compilers that at least implement the needed preprocessor instructions for guards. 防护措施至少应确保对于至少实现防护措施所需的预处理程序指令的所有编译器的基本假设均相同。
• On most compilers, #pragma once will speed up compilation (of one cpp) because the compiler will not reopen the file containing this instruction. 在大多数编译器上， #pragma once可以加快（一个cpp的）编译速度，因为编译器不会重新打开包含该指令的文件。 So having it in a file might help, or not, depending on the compiler. 因此，根据编译器的不同，将其保存在文件中可能会有所帮助。 I heard g++ can do the same optimization when guards are detected but it have to be confirmed. 我听说当检测到防护措施时g ++可以进行相同的优化，但必须进行确认。

Using the two together you get the best of each compiler for this. 结合使用这两种方法，您可以充分利用每个编译器的优势。

Now, if you don't have some automatic script to generate the guards, it might be more convenient to just use #pragma once . 现在，如果您没有自动生成保护程序的脚本， #pragma once使用#pragma once会更方便。 Just know what that means for portable code. 只是知道这对于可移植代码意味着什么。 (I'm using VAssistX to generate the guards and pragma once quickly) （我正在使用VAssistX快速生成防护和杂注）

You should almost always think your code in a portable way (because you don't know what the future is made of) but if you really think that it's not meant to be compiled with another compiler (code for very specific embedded hardware for example) then you should just check your compiler documentation about #pragma once to know what you're really doing. 您几乎应该总是以可移植的方式考虑您的代码（因为您不知道未来的前景），但是如果您确实认为它并不意味着要使用其他编译器进行编译（例如，用于特定嵌入式硬件的代码）那么您应该只查看#pragma once有关#pragma once的编译器文档，以了解您的实际工作。

---

#6楼

I generally don't bother with #pragma once as my code sometimes does have to compile with something other than MSVC or GCC (compilers for embedded systems don't always have the #pragma). 通常，我通常不会为#pragma once困扰，因为我的代码有时确实需要使用MSVC或GCC以外的其他语言进行编译（嵌入式系统的编译器并不总是具有#pragma）。

So I have to use #include guards anyway. 因此，无论如何，我必须使用#include防护。 I could also use #pragma once as some answers suggest, but there doesn't seem to be much reason and it will often cause needless warnings on the compilers that don't support it. 正如一些答案所建议的那样，我也可以使用#pragma once ，但是似乎并没有太多的理由，它通常会在不支持它的编译器上引起不必要的警告。

I'm not sure what time savings the pragma might bring. 我不确定实用程序可以节省多少时间。 I've heard that compilers generally already recognize when a header has nothing but comments outside of the guard macros and will do the #pragma once equivalent in that case (ie., never processing the file again). 我听说编译器通常已经可以识别标头在保护宏之外没有注释的情况，并且在这种情况下将执行#pragma once等效操作（即，不再处理该文件）。 But I'm not sure if it's true or just a case of compilers could do this optimization. 但是我不确定这是否是真的，或者只是一个编译器可以进行这种优化。

In either case, it's just easier for me to use #include guards which will work everywhere and not worry about it further. 无论哪种情况，使用#include防护对我来说都比较容易，它可以在任何地方工作，而不必担心它。