为什么C标准库中没有哈希表？
为什么没有Hashtable支持作为标准C库的一部分？ 这有什么特别的原因吗？
标准C库中没有散列表，因为：
- 没有人向工作组提交提案; 要么
- 工作组认为没有必要。
这就是ISO的工作方式。 build议提出并接受或拒绝。
由于有两个相互冲突的组，因此必须小心添加到标准库中。 作为一个用户，你可能希望每个太阳下的数据结构都被join标准中，以使语言更有用。
但是，作为一个语言实现者 （作为一个旁观者，这些人可能是组成大多数工作组的人，所以他们的观点可能会有更多的影响），你并不是真的想要实施的麻烦所有人都不能使用的东西。 当C89出现的时候，所有那些东西都是为了编纂现有的实践而不是引入新的实践。 自那时以来，所有标准的迭代已经有了一些自由度，但是向后兼容性仍然是一个重要的问题。
我自己也有冲突 我很想在C语言中使用Java，C ++或Python库的所有function。当然，这会让学习所有新手变得更加困难，正如一位评论者所说的，可能使得它代码猴子可以抽出有用的代码，在这个过程中减less我的价值:-)
而且我从很长时间（大部分）杰出的职业生涯中获得了所有我需要的数据结构。 你不限于这种东西的标准库。 有很多第三方工具可以完成这个工作，并且（像我一样）也可以推出自己的工具。
如果你想知道为什么在每次迭代中做出某些决定，ISO（和ISO最初在ISO接pipe之前）通常会发布基本文件。 ANSI的C89可以在这里find。 它包含了这个小范围内的美：
这一理论主要侧重于基础文件中所述的添加，澄清和对语言做出的修改。 它不是整个C语言的理由：委员会负责编纂现有的语言，而不是devise一个新的语言。 在这个理论基础上，没有尝试去捍卫语言的预先存在的语法，比如声明的语法或者操作符的绑定。
我尤其喜欢承认，他们不负责任何邪恶的混乱，可能早于他们的标准化尝试。
但是，你的问题的真正答案可能在于这个指导原则之一：
保持C的精神。委员会始终把保持C的传统精神作为主要目标。C的精神有很多方面，但本质是C语言所依据的基本原则的社会情感。 C精神的一些方面可以用下面的短语来概括：
- 相信程序员。
- 不要阻止程序员去做需要做的事情。
- 保持语言小而简单。
- 只提供一种方法来执行操作。
- 快速，即使不能保证便携。
第三个可能是图书馆没有经过最初的标准化努力而大规模扩展的主要原因，而且这样一个委员会的扩展可能导致ANSI C被标记为C2038而不是C89。
按照今天的标准，C似乎并不常见，因为没有定义有用的数据结构。 没有。 甚至没有string – 如果你认为Cstring是一个数据结构，那么我们将不得不不同意“数据结构”是什么。
如果你喜欢C，那么把它看作是一个“空白的石板”……你的整个应用程序是由你自己编写的代码和你select的库所组成的，还有一些相当原始的标准库函数，可能有一两个例如qsort 。 现在人们使用C来实现诸如Python，Ruby，Apache或Linux内核之类的东西。 这些项目无论如何都是使用自己的数据结构，而且他们不太可能使用像STL这样的东西。
许多C库实现通用的哈希表。 有权衡，你可以select你最喜欢的。 其中一些可以使用callback进行configuration。
- Glib有一个哈希表对象（ 文档 ）
- Apache便携式运行时有一个哈希表（ 文档 ）
- 苹果的核心基础库有一个哈希表（ 文档 ）注：是的，你可以插入任何对象作为键或值。
- UTHash是一个哈希表库（ 文档 ）
- 另一个哈希表库（ 链接 ）
所有这些库都可以做你想做的事情，那么为C标准添加一个哈希表有什么意义呢？
标准的C库不包含任何大的，持久的数据结构 – 既不是列表也不是树，也不是堆栈，也不包含哈希表。
如果不询问原始C库的作者，就不可能给出明确的答案。 然而，一个合理的解释是，这种数据结构的实现涉及到各种折衷，只有应用程序的作者处于正确的位置才能做出折衷。
请注意，POSIX标准C库确实指定了通用的散列表函数： hcreate() ， hsearch()和hdestroy() ; 并且还指出，它们的“一刀切”性质往往使它们不适合大多数现实世界的用例，支持上述论点。
由于缺乏模板
这是一个猜测，但是像C ++这样的语言中没有模板使得实现容器非常不雅，因为你需要几十个定义来覆盖所有可能的types，更不用说用户定义的types。
有C策略来缓解这个问题，就像使用void * ，但是它们会丢失编译时types检查。
GLib和gnulib是我目前推荐的实现： 快速实现C语言中的字典
