我在一个环境中工作，由于历史原因，我们正在使用自定义实用程序类的大杂烩，其中大部分是在 STL 出现之前编写的。我认为至少使用 STL 编写新代码是个好主意的原因有很多，但主要原因是我相信它可以提高程序员的工作效率。不幸的是，我不知道如何证明这一点。
是否有任何研究试图量化甚至只是暗示使用 STL 可以提高生产力？
更新：我想我应该更具体一些。我不提倡重写现有代码，我不担心新员工会获得良好的开端。前者是愚蠢的，后者本身不足以说服人。
【问题讨论】：
没有研究表明 STL 仅仅因为它是 STL 就更高效。使用它带来的生产力提升是因为它是标准程序员熟悉它，而且代码已经编写和测试。
如果您的公司已经拥有员工熟悉的实用程序类，并且此实用程序代码在整个现有代码库中使用，那么切换到 STL 实际上可能会损害生产力。
也就是说，对于使用 STL 的新代码将是一个不错的举措。我不一定会从生产力的角度来争论这一点，而是从可维护性的角度来争论。如果您的代码早于 STL，听起来您公司的代码生命周期相当长，并且很可能多年来由许多新程序员维护。
您可能还想提出使用 STL 来让每个人都保持其 C++ 技能集的敏锐度。虽然我不会拒绝不了解 STL 的 C++ 候选人，但我肯定会将其视为一个黑标。
【讨论】：
STL 如此“好”的原因仅仅是因为它已经存在了很长时间，并且其实现已经吸引了很多用户和关注。它们经过了很好的调试，并且算法已经被供应商很好地优化了。
STL 对于您商店中的新开发人员来说会更有效率，因为他们很可能已经熟悉它。您的自定义库将是外来的，并且可能缺少开发人员习惯使用的功能。不过，在新开发者的初始提升期之后，这并不是一个大问题。
没有真正迫切的理由仅仅因为它是转向 STL。如果您的应用程序中有非常有用的实用程序类，我建议您坚持使用它们，除非它们不适用于新代码。在新代码中将 STL 与自定义库混合会在某些时候导致兼容性问题，并且重构代码以使用所有 STL 会引入错误。无论哪种方式，您都会失去生产力。
编辑：“新”代码是指使用旧类库的现有应用程序中的新代码。
如果您正在开发不使用任何旧应用程序代码的新独立应用程序，我建议您使用 STL，因为它存在，大多数 C++ 开发人员都知道如何使用它，而且它非常稳定（并且您可以从您的工具集供应商（如果不是）。
【讨论】：
我能想到的使用 STL 提高生产力的唯一理由是可以轻松集成其他库 - Boost、Arabica、SOCI 等。它们都是为使用 STL 而设计的，而不是您的内部容器类。
【讨论】：
我认为关键因素是开发团队的人员流动率。
如果团队稳定，并且他们已经在此代码上工作了 10 年，并且可能会在 10 年后，他们会使用他们熟悉的实用程序类来提高工作效率，并推动他们使用STL 将导致生产力下降和错误。
如果团队翻了很多次，那么新开发人员可能会熟悉 STL，显然不会熟悉这个专有的实用程序类库，并且会更好地使用 STL。
【讨论】：
我也遇到过同样的情况。这取决于相关的实用程序类。我见过的许多自定义实用程序类都存在错误或设计不佳，并且导致整个源代码出现错误和效率低下。在这种情况下，直接替换为 STL 等效项将改进代码库、提高生产力、减少错误并降低未来的维护成本。
您有时可以通过将 STL 样式的迭代器改装到您的旧类来帮助弥合这两个世界之间的差距，但要小心使它们正确！
【讨论】：
如果本土实用程序以任何方式特定于您所做的工作的领域，情况可能正好相反。
【讨论】：
STL 有用的地方不是在 STL 提供的实际库等中，而是在 STL 使用的编码风格中。
以下需要进行 2 个主要测试：
struct DoSomething {
bool operator ()(Container::value_type const & v) const
{
// ...
}
};
void bar (Container const & c)
{
std::for_each (c.begin (), c.end (), DoSomething ());
}
第一个测试验证 'DoSomething::operator()' 做了它应该做的事情。第二个测试只需要验证“DoSomething::operator()”是否被调用。
与手写 for 循环相比，这种分离有助于提高工作效率。对于上述情况，测试的数量是“要完成的事情”和对非空容器进行调用的测试的总和。在 for 循环的情况下，测试的数量是测试的乘积。
【讨论】：
我看到的原因是：
STL 的编写者（无论是它的接口，还是您的编译器的实现）无疑比贵公司最好的开发人员要好很多。
他们的工作是制作一个可用的 STL，这意味着无论如何每个函数/方法/对象都经过大量测试。
随着营业额的增加，一些代码可能会变得缓慢而隐秘地无人维护。这意味着如果此代码中存在错误，或者如果发现其性能或界面缺乏（参见上面的“质量”），那么您将找不到任何人来熟练地改进它。
代码更改在其他地方出现代码回归的概率不为零，如果您的内部库没有经过单元测试，那么这种回归将在很长一段时间内未被检测到。
当有人试图纠正代码时发现他不明白为什么要这样做（因为宏，奇怪的 pre -条件等。
将两者结合起来，您会发现对于泛型代码（即数组、字符串等），通过从内部库缓慢迁移到 STL 库并在需要时编写“转换器函数”会更好.
我认为这种迁移是代码维护的一部分，您应该尽可能缓慢地（即使用新代码或重构时）使用 STL 而不是内部通用库。
【讨论】：
由于您已经拥有实用程序类，因此无需使用 STL。当您发现需要开始将 STL 集成到实用程序库中时，它将很快成为一个可维护性问题。 IMO，这将是生产力损失。
也就是说，STL 可能提供许多实用程序库不提供的特性和实用程序。 （特别有用的是
不过，我不知道有关该主题的任何研究。
【讨论】：
考虑一下您雇用新的 C++ 程序员时的情况。她/他更有可能有 STL 课程的经验还是您自己的课程？如果您开始切换到 STL，您可能会在它们变得高效之前节省大量时间。
【讨论】：
目前，任何新聘用的员工都必须学习如何使用旧课程，这需要时间和金钱。像其他人一样使用 STL 可以为您的公司节省资金并使其在候选人群中保持吸引力。
【讨论】：
不幸的是，我认为没有办法证明批发替换这些自定义类是合理的。如果可能，将它们替换为一个类的 STL 组件。
这是一个维护和可读性问题。 (1) 使用 STL 可以帮助维护人员一目了然地理解代码，而不是需要了解如何解决自定义实现。 (2) STL 有很好的文档记录并且很好理解——您的自定义类呢？ (3) STL 经过严格审查。 (4) STL 带有渐近运行时上限和下限。
祝你好运。
【讨论】：