哈希表标准C库的一部分？ [英] Hashtable as part of Standard C Library?

问题描述

这是为什么没有Hashtable的支持，标准C库的一部分？是否有任何具体的原因？

Why is that there is no Hashtable support as part of Standard C Library? Is there any specific reason for this?

推荐答案

有在标准C库中没有哈希表，因为无论：

There is no hashtable in the standard C library because either:

• 没有人提交了一份提案，工作组;或


• 工作组认为有必要的。

这是ISO的工作方式。提案提出并接受或拒绝。

That's the way ISO works. Proposals are put forward and accepted or rejected.

您必须小心你加什么标准库，因为你有两个相互矛盾的群体。作为一个的用户的你可能想在阳光下的数据结构被添加到标准使语言更加有用。

You have to be careful what you add to the standard library since you have two conflicting groups. As a user, you might want every data structure under the sun to be added to the standard to make the language more useful.

但是，作为一种语言的实施者的（顺便说一句，这些都可能是趋向于上大多数是各工作组，以便他们的观点是可能有更多的影响的人），你不'吨真的想不必实现的东西，可能不是每个人都可以使用的麻烦。所有这一切在那里当C89出现东西是与事实的主要目的是编纂现行的做法，而不是引进新的做法去做。自那时以来，该标准所有迭代已经在他们可以做什么一点点自由，但是向后兼容性仍然是一个重要的问题。

But, as a language implementor (as an aside, these are probably the people that tend to make up most of the various working groups so their view is likely to have more impact), you don't really want the hassle of having to implement stuff that may not be used by everyone. All the stuff that was there when C89 appeared was to do with the fact that the primary purpose was to codify existing practice rather than introduce new practices. All iterations of the standards since then have been a little freer in what they can do but backwards compatibility is still an important issue.

我自己，我也有冲突。我很想对Java，C ++或Python库的所有功能，在我的处置C.当然，这将使它所以更难学习一切对新人，正如一位​​评论者所说，可能使它所以任何code猴子能泵出有用的code，减少我在这个过程中的价值： - ）

Myself, I also have conflicts. I'd love to have all the features of the Java, C++ or Python libraries at my disposal in C. Of course, that would make it so much harder to learn everything for newcomers and, as one commenter stated, probably make it so any code monkey can pump out useful code, reducing my value in the process :-)

和我pretty多的有无的所有数据结构，我会永远需要，从我的长和（大部分）杰出的职业生涯。你不是局限于标准库这样的东西。有大量的第三方工具，你可以得到做的工作，并（像我一样），你也可以推出自己的。

And I pretty much have all the data structures I'll ever need, from my long and (mostly) illustrious career. You're not limited to the standard library for this sort of stuff. There are plenty of third-party tools you can get to do the job and (like me) you can also roll your own.

如果你想知道为什么某些决定在每次迭代中进行了改造，ISO（和ANSI原来，之前ISO接手），通常公布的理由的文件。从ANSI C89的人可以在这里找到 。它包含了这个小美女的范围：

If you want to know why certain decisions were made in each iteration, ISO (and ANSI originally, before ISO took over) usually publish rationale documents. The C89 one from ANSI can be found here. It contains this little beauty in the scope:

这个原理作为基础的文档描述主要侧重于补充，澄清，并以语言的变化。这不是C语言作为一个整体的理由：该委员会负责编纂现有的语言，而不是设计一个新的。没有试图在这个原理制成保卫pre-现有语言的语法，如声明的语法，或者运营商的结合。

This Rationale focuses primarily on additions, clarifications, and changes made to the language as described in the Base Documents. It is not a rationale for the C language as a whole: the Committee was charged with codifying an existing language, not designing a new one. No attempt is made in this Rationale to defend the pre-existing syntax of the language, such as the syntax of declarations or the binding of operators.

我特别喜欢，他们是不负责的，可能有predated他们试图标准化任何邪恶一塌糊涂入场。

I especially enjoy the admission that they're not responsible for any unholy mess that may have predated their attempts to standardise.

不过，也许真正回答你的问题就在于此位，指导负责人之一：

But, perhaps the real answer to your question lies in this bit, one of the guiding principals:

保持C的精神。委员会保持为主要目标，以preserve C的传统精神有C的精神的许多方面，但本质上是一个社区赖以C语言所依据的基本原则情绪。一些C的精神层面的可以归纳为短语，如：

Keep the spirit of C. The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like:

• 相信程序员。


• 从做需要做什么，否则不要prevent程序员。


• 保持语言小而简单。


• 只提供一种方法做一个操作。


• 请它速度快，即使它不能保证便携。

这是第三个可能就是为什么该库没有大量的初始标准化工作扩大的主要原因 - 这一点，事实上，从委员会的这种扩大可能会导致ANSI C被标记C2038而非C89

That third one is probably the main reason why the library wasn't massively expanded with the initial standardisation effort - that, and the fact that such an expansion from a committee would probably have resulted in ANSI C being labeled C2038 rather than C89.

这篇关于哈希表标准C库的一部分？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！