C ++标准库 – 我应该什么时候使用它，什么时候不应该？
我想知道人们实际上多less使用标准c ++库，特别是<algorithm>和<numeric>头文件中的东西。 教科书似乎推荐了他们，但是我从来没有看到他们中的任何一个在我经历过的各种项目中都使用过（巧合？），并且亲自看起来更简单，只要每次都自己编写适当的简单algorithm，而不是记住或每次请查阅这些标题的参考。 我只是懒惰或固执？ 使用这些库时是否有性能上的提升？
谢谢，
[R
这可能是你懒惰或固执。 就我个人而言，我一直在生产代码中使用它们。
我不会这么做，我不这样做，因为我喜欢写“太空时代的代码”。 相反，我这样做是因为我是一个偏执狂的程序员，而且我知道生产环境是一个充满敌意的地方，如果有机会的话，这些地方会毁坏代码并把我的程序减less到一堆无用的字节。
我这样做，是因为我靠的座右铭，“最好的代码，是你永远不会写的代码”。 学习如何有效地使用STL和Std库需要花费一些时间，但是一旦你这样做了，你会发现它可以被使用，现在1000行代码变成了100个。这100个代码可能需要花费尽可能长的时间来写原来的1000，但是有更less的失败点。 如果你站在别人的肩上，代码可以更强大。
你应该尽可能使用stl。
它是由非常复杂的程序员写的，你不可能写任何stl东西的更优化的版本。
不要重新发明轮子
几乎所有使用C ++的人都使用STL， 特别是 <algorithm> 。 你真的不想自己编写sortingfunction， 你最终会犯错误，最终performance可能会更糟糕。
是否有性能提升显然取决于你的比较。 一般来说，使用STLalgorithm通常比编写你自己的函数要快 – 除非你碰巧有一个适用于你的用例的特殊技巧，可以给你一个优势。 如果你自己写一个标准的quicksort，它可能会比STL中的慢。
什么时候应该使用C ++标准库？ 当它提供你需要的function。
众所周知，像for_each这样的一些东西在语言上并不是非常好的支持，这就是C ++ 0x中的lambda。
你在筛选什么项目？ 这些专业项目还是随机的？
我注意到的一件事是，很多遗留types的代码（我在C ++ 98之前的代码库上工作）避免了C ++标准库，因为当时的实现性能方面的担忧，或者只是因为当时图书馆不存在。 当然，有些环境（embedded式系统，游戏，国防等）也可能有其他的要求，在很多情况下都不能使用C ++标准库，比如我的一个防务工作的同事，根本不能使用STL的东西，由于客户要求不使用它。
一般来说，如果可以select使用标准库，而不是使用别人的库来创build自己的车轮，那么总的来说，我会先select第一个选项。 代码经过数千，数十万人的testing，受到比自己实现的大多数事情更多的testing和审查。
第三方库（让我们挑选一个像Boost的例子）如果它有你需要的东西。 像Boost这样的图书馆是受人尊敬的，有着卓越的质量代码的声誉，并被很多人使用/testing/维护。
最后的select是你自己的代码的发明，我认为这确实属于几个类别：
- 自学 – 写代码只是为了学习，但这意味着你不会把它当作生产代码来运输。
- 你有具体的要求，不能被任何可以获得的东西所满足，或者必须从别的东西中进行调整。 有很多这个，你可能需要编写自己的algorithm，针对你正在做的任何事情。
但是要记住，如果你自己实现了，那就考虑一下标准库是否已经有了它，否则如果你的代码中有些东西变得非常根深蒂固，那么你可能会遇到一个维护问题。 我最后一个公司实现了自己的容器类，当然代码库增长了数百万行代码（大量产品），每个人都使用这些内部开发的容器类。 这些容器中的错误花费了大量的开发人员时间和金钱来修复，因为这些类只有基本的错误（链接列表，向量，关联数组，标准C ++没有提供）。 当新代码使用标准库时，公司只是没有资源开始重构所有旧代码。
如果你可以把这种担心卸载到其他有此类代码经验的开发人员，并得到数千人的testing？ 这是一个巨大的胜利！
很多现有的C ++项目都没有使用标准库，因为它们是在可以依赖标准库之前启动的 – 我正在谈论的代码在这里有十到十五年的发行历史。 我也听说，一些现代化的环境（例如Android） 仍然没有给你一个完整的C ++运行库，所以如果你需要可移植到这些环境，你仍然不能使用它。
另一个原因是一些非常大的程序（我个人对Firefox的胆量有个体验，而且我也听说OpenOffice也是如此）是在禁用exception支持的情况下构build的，因为它被认为会导致性能问题（这可能实际上对于MSVC ++的ABI和/或对于荒谬大小的程序（比如上述两个）来说都是正确的），但是如果你这样做的话，你不能使用大部分的C ++运行时。
这是令人沮丧的，但这是亚行业。
这不是对你的问题的直接回答，对不起。 只是一个哭泣。 我读过以前的答案，并决定增加我的两分钱。 特别是关于<algorithm>和<numeric>
什么是主要的C ++范例？ 当然，OOP，树鲸等每一个C ++面试都有一个关于这个问题。 但我从来没有被问及函数式编程。 <algorithm>和<numeric>是function部分恕我直言。 为了积极使用它们，你需要考虑一些不同，把你的程序构build成一个使用地点。 典型的推理：为什么使用任何sorting，如果我可以使用std :: map或std :: set？ 这不是一个过早优化的恶魔吗？ 最终结果将在绝大多数情况下被接受，只是购买更好的硬件。 比较简单的代码实现通常要比学习100多种algorithm更重要，要了解如何以及何时使用它们。 这是完整的火箭科学。
考虑统计平均软件公司与100 C ++程序员。 将会有大约10位优秀的专家。 他们有没有机会在那里传播好的风格？ 是的，如果他们是天生的领导者，并且在公司工作足够长时间。 他们需要不断地与“例外是非常糟糕的想法”，“虚拟方法很慢”，“它只是一个int ，为什么不是线程安全的”这样的偏见进行斗争。 而且由于密集的<algorithm>和<numeric>用法，他们的代码不能被其他人理解
您应该使用所有语言的标准库，而不仅仅是C ++。 这几乎是编程这些天的基本规则。
你的印象是错误的。 任何一个好项目都将从build立在已知的，经过testing的图书馆中受益 这些图书馆背后的时间和工时只是个人无法独自完成的事情。
为了让这些图书馆能够正常运行，许多人为了这些图书馆的努力，多年来一直饱受煎熬，汗streamswe背。 编写，debugging和争论每个特定实现细节的共同努力可能可以在几十年内测量。 最重要的是，不可数的机器周期已经花费在testing后的运行testing上，以确保一切工作符合规格。
然而几乎每个程序员都有这个想法。 你知道那个
“我可以在一个晚上做得更好”。
我知道。 我明白。 我去过那里。
前进。 这是一个很好的经验。
一条漫长而曲折的道路将延伸到你面前。 在旅程的最初阶段，你会发现很less有实现鹅卵石在这里和那里。 他们中的一些将滑入你的鞋子，大多数不会。
稍后的道路将停止如此直线; 它将开始分支。 很快你会发现自己经常尝试许多不同的path和回溯。 偶尔你会遇到algorithm不确定性或一个令人厌烦的重构山的深刻chasms。
所有这一切，当你看着你的同事在干净，直，维护的标准图书馆高速公路上超速驾驶。
逐渐地，你会意识到拒绝使用标准库，不仅仅是懒惰或固执，而是愚蠢的。 而且非常低效！
总而言之，如果你想到达某个地方，不pipe你能跑多快，驾驶一辆汽车将会更快，更安全地到达那里（除非你到楼下的商店买一些牛奶）
