ISO/IEC 9899:2011 (E):
6.10.2.5
该实现可以忽略字母大小写的区别,并将映射限制为句点前的八个有效字符。
由于stdatomic.h
句号前有 9 个字符,是否与上述(潜在)限制相矛盾?即,当将它们用作指令的参数时,某些实现不会区分stdatomic.h
和(例如)?stdatomix.h
#include
额外的问题:为什么stdatomic.h
而不是atomic.h
?
ISO/IEC 9899:2011 (E):
6.10.2.5
该实现可以忽略字母大小写的区别,并将映射限制为句点前的八个有效字符。
由于stdatomic.h
句号前有 9 个字符,是否与上述(潜在)限制相矛盾?即,当将它们用作指令的参数时,某些实现不会区分stdatomic.h
和(例如)?stdatomix.h
#include
额外的问题:为什么stdatomic.h
而不是atomic.h
?
如果您正在使用,则应#include <stdatomic.h>
包含库标题。但是用or做同样的事情(或不做同样的事情)是自由的#include <stdatomi.h>
#include <stdatomix.h>
但#include <stdatom.h>
应视为不同的文件。但另一方面,没有什么明确禁止实现拥有stdatom.h
只有内容为#include <stdatomic.h>
. 并不是说任何实现都会这样做,但它是允许的。
这里没有真正的矛盾。只是一个有趣的结果。
该实现可以忽略字母大小写的区别,并将映射限制为句点前的八个有效字符。
由于 stdatomic.h 在句点之前有 9 个字符,它是否与上面的(潜在)限制相矛盾?
不,因为虽然它使用了“限制”这个词,但这并不是对语言或实现的限制。这是赋予实现的自由。
即,当使用它们作为#include 指令的参数时,某些实现不会区分stdatomic.h 和(例如)stdatomix.h?
实现没有区分这两者,因为包含文件名不会使其不符合任何方式。该标准规定了形式的包含指令的特殊意义
#include <stdatomic.h>
. 只要实施承认该指令并赋予其必要的意义,就标准而言,是否
#include <stdatomix.h>
被赋予相同的意义。
额外的问题:为什么是 stdatomic.h 而不是 atomic.h?
虽然不是普遍遵守的约定,但在标准库头文件的名称前加上“std”是一种常见的约定。其他示例包括stdalign.h
、stdarg.h
、stdbool.h
、stddef.h
、stdint.h
、stdio.h
和。我不确定委员会对此的政策,但肯定的影响之一是减少添加到标准库的新标头名称与现有项目使用的标头名称冲突的可能性。stdlib.h
stdnoreturn.h