非标准的#pragma once功能几乎在所有C编译器上实现,但C标准排除了它.

The usual explanation为什么#pragma once,或者某些语言​​结构,它执行#pragma曾经做过的,已被排除在C标准之外的是,硬链接和复制的头文件要么会破坏#pragma一次,要么会激发编译器的启发式.公平地说,启发式算法通常与C哲学不相容,但是对于简单的破坏：有许多有用的语言特性可以打破,而不仅仅是#pragma once.管理此类破坏的正常C方法是让编译器在可疑实例中发出可选警告.毕竟,C是故意设计的,当一个人希望这样做时,让一个程序不安全和/或不可移植.此外,#pragma一次的不安全和/或不可移植性非常小.虐待并不容易.

当通常包含其他可用但有用的语言功能时,为什么#pragma曾被排除在标准之外？ #pragma曾经有过一些特别之处吗？

此外,在哪里可以阅读标准委员会最近对此事的审议？是否有一些委员会成员或委员会的追随者发表了最近的辩论摘要？

解决方法:

有几个简单的原因：

>通常比实现和指定它更难.由于实现通常不涉及颠覆该特征的方法,因此实现它的论点并不多.
>委员会时间更合理地用于处理模块,这使得大多数预处理器不需要尝试改进我们想要摆脱的东西.
>对于没有#pragma一次,有一个简单的解决方法(包括警卫),即它不被认为是一个问题.
>看起来,现有的实现确实表现不同,这似乎是最近讨论之一的根源.当然,这意味着标准化会很好,但随后会立即开始与2冲突.讨论并不简单,因为不同的各方都希望保留其各自的行为.
>我没有进行过于彻底的搜索,但我也没有看到提案：如果没有人写一个提案[并通过这个过程进行游说]没有任何标准化.也就是说,我完全相信上面给出的理由可以阻止添加#pragma的提议一旦有足够的多数就可以很快停止.

最近有一个关于提案邮件列表的讨论(关于如何注册,请参阅isocpp.org;但我现在无法访问此站点).但是,我并没有过于彻底地遵循它.快速浏览它我看到了上面给出的四个原因(我浏览后添加的第四个原因).

以下是最近邮件列表讨论中的一些参考：

> Is #pragma once part of the standard?
> Why isn’t C/C++s #pragma once standard?
> modules proposal