#ifdef/#define Include-Guard 之前的#include 可以吗？答案

【问题标题】：Is an #include before #ifdef/#define Include-Guard okay?#ifdef/#define Include-Guard 之前的#include 可以吗？
【发布时间】：2014-01-26 03:26:43
【问题描述】：

我总是将#include 放在#ifdef/#define Include-Guard 之后。现在我的 IDE（Qt Creator）的重构机制将它放在 Include-Guard 之前，例如

#include "AnotherHeader.h"

#ifndef MYHEADER_H
#define MYHEADER_H

这会导致任何问题吗？或者我可以这样吗？

【问题讨论】：

只要确保你在 "AnotherHeader.h" 中也包含了守卫，如果它是你的。
这个问题好像和qt标签没什么关系，所以去掉吧。
即使编译成功，您的代码的每个读者都会想知道为什么您在守卫之前包含文件。仅当您的团队普遍采用此类代码时，您才应提交此类代码。
很好奇。我想知道为什么 Qt Creator 会这样做。

标签： c++ include header-files include-guards

【解决方案1】：

如果有问题的标头本身包含保护，您就不会遇到问题。将它放在包含保护中仍然可以加快编译速度。编译器看不到的东西需要更少的时间来编译，即使它不会产生任何错误。

【讨论】：

IIRC，GCC 检测到标头保护模式并排除进一步的重复包含。但是，像 OP 所做的那样做可能会破坏它，从而抵消编译速度的提升。

【解决方案2】：

只需检查一下，会发生什么。假设，两个不同的标头使用MyHeader.h。

无条件包含AnotherHeader.h
包含保护允许加载头文件的其余部分。

下次：

再次无条件包含AnotherHeader.h
包含防护可防止加载头文件的其余部分。

如果AnotherHeader.h 是包含保护的，则不会发生任何不好的事情。但通常我会将 include-guard 放在文件的顶部 - 当它已经加载一次时，再次加载 AnotherHeader.h 是没有意义的。

【讨论】：

【解决方案3】：

虽然不太常见，但我认为这被认为是可以接受的，但请注意：如果您有循环 #include，您的包含通常会永远相互包含（直到预解析器抱怨最大包含深度为到达）。 #include 在包含保护之后不会发生这种情况。

(Circular #include's 在任何情况下都被认为不是好的样式，但如果仍然使用它，它可能会与#include's 在包含防护之后一起使用，但肯定会赢't 与#include 的之前他们。）

【讨论】：

这就是为什么我建议将它们放在包含保护之外的原因，因为这样你就会知道你是否创建了循环#include。