为什么在包含守卫之前放置#include

Question

在头文件中的包含防护之前放置 #include 指令是否有任何正当理由：

#include "jsarray.h"
#include "jsanalyze.h"
#include "jscompartment.h"
#include "jsgcmark.h"
#include "jsinfer.h"
#include "jsprf.h"
#include "vm/GlobalObject.h"

#include "vm/Stack-inl.h"

#ifndef jsinferinlines_h___
#define jsinferinlines_h___

//main body mostly inline functions 

#endif

请注意，此示例取自现实生活中一个备受瞩目的开源项目，该项目应由经验丰富的程序员开发 - Firefox 10 中使用的 Mozilla Spidermonkey 开源 Javascript 引擎（最新版本中也存在相同的头文件）。

在备受瞩目的项目中，我认为其设计背后一定有一些合理的理由。#include在包含守卫面前有什么正当理由？它是适用于仅内联函数头文件的模式吗？另请注意，此头文件 (jsinferinlines.h) 实际上通过包含 #include "vm/Stack-inl.h"保护之前的最后一个指令（此头文件包含许多其他头文件，其中一个实际上再次包含此 jsinferinlines.h）指令包含自身，这使得更少对我来说有感觉。

Answer 1

当时 SpiderMonkey 标头中有很多包含循环，并且将标头保护放在顶部会导致难以理解的编译错误 - 我怀疑将标头保护放在包含下面只是清理包含的一个增量步骤。

不过，我无法告诉您导致它产生影响的确切包含顺序。

如今，SM 标头中不应该有任何包含循环，并且它们的样式是通过 Nicholas Nethercote 编写的 python 脚本强制执行的。如果您今天查看 jsinferinlines.h，您会看到标头防护位于其所属的顶部。