【问题标题】:Should programmers use STL or write their own code? [closed]程序员应该使用 STL 还是编写自己的代码? [关闭]
【发布时间】:2011-07-26 14:02:58
【问题描述】:

我对 C++ 数据结构了解不多,但我想知道您(程序员)是使用 STL 还是编写自己的代码?毕竟 STL 是为通过数据列表执行搜索、替换等任务而设计的。

有些人真的不需要学习太多关于链表、二分搜索等等的知识,因为我可以使用 STL。你有什么建议?

【问题讨论】:

  • 不要重新发明轮子。这并不意味着不了解轮子的工作原理以及何时使用它的最佳时机,但 STL 是一个编写良好的库,使用起来很可能更安全/更快。
  • 我想这个问题不是那么开放
  • @Philip:为什么可怕?这听起来像是一个合理的、重要的问题要问我?
  • 可能被骗:我应该使用市政污水处理厂还是自己尝试?
  • @Enno Shioji 这就是我的意思。这是关于如何启动项目的高级决策。编程哲学。这是个好问题。对于程序员。但是堆栈溢出保留了这一点,并将所有不好的问题发送给程序员。我们感觉在那里受到了虐待。

标签: c++ stl


【解决方案1】:

您应该使用 STL,因为它经过了良好的测试和优化。

这并不意味着您不应该自己知道如何编写这些数据结构。凭借这种能力,您将能够为您的应用程序选择最佳的 STL 数据结构。

【讨论】:

  • 我认为,接受的答案是错误的。该标准对于是否编写自己的容器是严格中立的。
【解决方案2】:

虽然标准模板库在执行您提到的搜索、替换、使用链接列表等任务时很方便,但它不应取代对库内部发生的事情的了解.

您提到不需要了解链表、二进制搜索和“更多”,但是您至少应该了解这些数据结构和过程在使用它们时的工作原理(并知道何时使用它们)更有效。

基本上 - 你不必重新发明轮子,但至少知道是什么让轮子有效地转动。

【讨论】:

    【解决方案3】:

    尽可能使用 STL 和标准库。首先,它可能比您自己的代码经过更好的测试,其次它有助于保持代码的可移植性。您应该重写任何此功能的唯一时间是出于学习目的。编写自己的关联图或链表可能具有教育意义,但对于生产代码,请坚持使用经过良好测试且符合标准的代码。

    【讨论】:

      【解决方案4】:

      了解 STL 提供的工具的底层数据结构、方法和应用程序将使您成为更好的程序员。知道什么时候使用什么容器类型,或者什么算法与正确的实现一样重要。有时,理解一些更复杂概念的最简单方法是在数据结构和算法类的上下文中自己实现它们。

      也就是说,STL 中的代码是由专家编写的,并随着时间的推移被提炼成一个标准库,全世界数以百万计的人都在使用它。实际上,除了性能(或大小)对您的确切应用至关重要的极端情况外,几乎没有理由“自行开发”。

      【讨论】:

        【解决方案5】:

        我犹豫不决,因为我已经 5 年没有写过 C++了。但是我想到了一些尚未讨论的事情。

        如果实现不适合您的需要,如果您自己编写和测试比使用库更容易,请不要使用它。我最近在 Java 中遇到了这个问题,我需要一个快速的 bitset。细节::JVM中有两个相关的类(BitSet和BigInteger)。 BitSet doesn't support initialization other than by setting one bit at a time; BigInteger 有一个不相关的符号,会混淆事物,并且是不可变的,这在我的情况下是昂贵的。我最终在几个小时内编写了自己的测试。它更合身、更快,而且我可以为所欲为。

        编写自己的另一个原因是,如果您不了解与您的需求相关的库实现规范,无法轻松测试或阅读它以弄清楚它的作用,并且可以轻松推出自己的.这是/曾经是 STL 实现的一个特殊问题,这些实现(或至少曾经是)附带简洁、不充分、神秘的文档和无注释、不透明的源代码,就像巨大的流氓浪潮一样在你头上滚动。

        【讨论】:

          【解决方案6】:

          只是添加我的答案(来自上面的评论):

          是的,您应该考虑实施例如一个序列,一个链表,使用你自己的代码。

          这是他们在 Comp Sci 课程中教授的内容,这并非没有充分的理由。但是,如果您希望快速工作,那么只需使用 STL。

          我只是认为人们应该了解这些工具的真正工作原理。

          【讨论】:

          • 实际上,“数据结构简介”课程让您了解(并实现)这些结构,以便您可以选择最适合手头工作的结构。选择具有错误算法复杂性的数据结构可能是灾难性的。另外,有些问题需要对众所周知的数据结构进行巧妙的修改。由于它们不是普遍感兴趣的,它们可能不是由通用库提供的。
          • 要了解时间复杂度与数据结构之间的关系的唯一方法是通过实验。那么我猜想 STL 对于构建程序块总是有用的。
          【解决方案7】:

          我使用 C/C++ 标准库和 STL,因为它可以节省大量时间,而且我认为没有必要重新发明轮子。我也尽可能使用 boost。

          编写自己的容器类和算法仍然是一个很好的学习练习。

          【讨论】:

            【解决方案8】:

            除非您有令人信服的理由,否则请使用 STL,例如速度或正确性,不是。绝对知道如何自己编写基本的数据结构。

            【讨论】:

            • 正确性!您是在暗示它们是错误吗?
            • 不,只是 STL 中不存在数据结构/算法来正确解决您可以提出的每个问题。如果您的问题是您无法找到用 STL 解决问题的方法,那么编写自己的代码可能是唯一的选择。
            • @Martin:你的意思是说有一个 100% 没有错误的 STL 实现吗?
            • @Joe Wreschnig:取决于哪个版本。但我敢打赌,任何主要版本都是没有错误的(或者有很好的错误记录)。它们被大量使用和测试,任何错误都会引起很多喋喋不休。他们已经有 10 年以上的历史了,而且相对简单。所以是的,我愿意使用任何 STL 实现,就好像它 100% 没有错误一样。
            【解决方案9】:

            一般来说,您应该使用 STL 或 Boost 容器,因为它们的有效性和可靠性。您仍然需要对现有容器有相应的世界观。你应该知道它的缺点和优点。对容器内部结构和工作原理的研究可以让你更好地理解。

            【讨论】:

              【解决方案10】:

              STL 经过充分测试且可靠,但它不是最快的解决方案。一些容器分配了很多小内存块而不是一个大块。如果您确实有速度问题,那么您可以考虑制作自己的固定大小列表。但对于许多用途而言,STL 是标准解决方案。

              【讨论】:

              • "一些容器分配了很多小内存块而不是一个大块。" -- std::vector 没有,std::array 没有。当您可以使用其中任何一个时,创建自己的固定大小列表有什么好处?
              • 所有容器都允许您专门化分配器。默认版本非常快,并且可能会击败您可以编写的任何内容以尝试编写更快的版本。我认为不好的建议。
              • @Martin:STL 分配器模型很糟糕。如何为 std::list 创建节点池?没有可移植的方法,因为 std::list 不会公开它分配的节点的大小。任何真正关心性能的人都会使用更好的分配器模型编写自己的容器。
              • 任何通用库在某些特殊情况下都将无法正常运行。但由于最初的问题没有给出任何限制,因此建议编写自定义容器是没有意义的。
              • @Peter Alexander:我认为这并不可怕(但我确信在某些情况下它们不能以最佳方式工作)。但是我做了一些计算密集型的工作,我只有一次让容器成为我的代码中的瓶颈,需要一个自定义分配器来轻松解决问题。我敢打赌,标准容器会在效率上击败大多数初学者。
              【解决方案11】:

              非常聪明的人编写了 STL。然后更多非常聪明的人使用它,测试它,改进它。你认为你会做得更好吗?很少。这是一个很棒的工具;你应该尽可能使用它!

              【讨论】:

                【解决方案12】:

                在学习/玩耍时自己编写低级的东西,但在工作中使用由专家多年来编写和完善的代码,并且已经/正在由数千名工程师在数千种不同条件下进行测试。

                换句话说,只有在您的代码可以击败其他代码时才使用您的代码

                【讨论】:

                  猜你喜欢
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 2010-10-04
                  • 1970-01-01
                  • 2011-03-23
                  • 1970-01-01
                  • 2011-03-12
                  • 2020-10-19
                  相关资源
                  最近更新 更多