为什么ANSI C没有命名空间？
对于大多数语言来说，命名空间似乎是毫不费力的。 但据我所知，ANSI C不支持它。 为什么不？ 是否有计划将其纳入未来的标准？
C有命名空间。 一个用于结构标签，另一个用于其他types。 考虑下面的定义：
struct foo { int a; }; typedef struct bar { int a; } foo; 第一个标签是 foo，后面的是用typedef把它变成footypes的。 仍然没有名称冲突发生。 这是因为结构标签和types（内置types和types定义的types）位于不同的名称空间中。
C不允许的是按意愿创build新的命名空间。 C在语言中被认为是重要的之前就已经被标准化了，并且添加命名空间也会威胁向后兼容性，因为它要求名称修改才能正确工作。 我认为这可以归因于技术，而不是哲学。
编辑：JeremyP幸运的纠正了我，提到了我错过的命名空间。 标签和结构/联合成员也有名称空间。
为了保持完整性，有几种方法可以实现从命名空间中获得的“好处”，在C中
我最喜欢的方法之一是使用一个结构来容纳一堆方法指针，这些指针是你的库/接口等。
然后你使用这个结构的外部实例，在你的库中初始化，指向你所有的函数。 这可以让你保持你的名字简单的在你的库中，而不必踩在客户端名称空间（除了全局范围的外部variables，1个variables，也可能是数百个方法..）
还有一些额外的维护，但我觉得这是最小的。
这里是一个例子：
/* interface.h */ struct library { const int some_value; void (*function1)(void); void (*method2)(int); /* ... */ }; extern const struct library Library; /* interface.h */ /* interface.c */ #include "interface.h" void method1(void) { ... } void method2(int arg) { ... } const struct library Library = { .method1 = method1, .method2 = method2, .some_value = 36 }; /* end interface.c */ /* client code */ #include "interface.h" int main(void) { Library.method1(); Library.method2(5); printf("%d\n", Library.some_value); return 0; } /* end */
指某东西的用途 。 语法在经典的Library_function（）Library_some_value方法上创build了一个强大的关联。 但是有一些限制，你不能使用macros作为函数。
C有命名空间。 语法是namespace_name 。 你甚至可以将它们嵌套在general_specific_name 。 如果您希望能够在不每次写出名称空间名称的情况下访问名称，请将相关预处理器macros包含在头文件中，例如
#define myfunction mylib_myfunction
这比名字重组更清晰，某些语言承诺提供命名空间的其他暴行。
历史上，C编译器不会破坏名称（它们在Windows上执行，但是对cdecl调用约定的修改只包括添加下划线前缀）。
这使得使用其他语言的C库（包括汇编程序）变得很容易，这也是您经常看到C ++ API的extern "C"包装的原因之一。
只是历史的原因。 没有人想到当时有一个像命名空间的东西。 而且他们真的试图保持简单的语言。 他们可能会在未来
不是一个答案，但不是一个评论。 C没有提供明确定义namespace的方法。 它有可变的范围。 例如：
int i=10; struct ex { int i; } void foo() { int i=0; } void bar() { int i=5; foo(); printf("my i=%d\n", i); } void foobar() { foo(); bar(); printf("my i=%d\n", i); }
您可以为variables和函数使用限定名称：
mylib.h void mylib_init(); void mylib_sayhello();
与命名空间唯一的区别是你不能using它，不能from mylib导入。
ANSI C是在命名空间之前发明的。
因为那些想为C增加这个能力的人并没有组织起来对编译器作者团队和ISO团体施加压力。
