什么是错误的cplusplus.com？
对于这个问题，这可能不是一个完美的合适的论坛，但让我试试吧，冒着被移走的危险。
有几个C ++标准库的参考资料，包括无价的ISO标准， MSDN ， IBM ， cppreference和cplusplus 。 就个人而言，在编写C ++时，我需要一个具有快速随机访问，快速加载时间和使用示例的参考，而且我一直在寻找cplusplus.com非常有用。 不过，我一直在这里经常听到有关该网站的消极意见，所以我想具体说明一下：
cplusplus.com给出的错误，误解或不好的build议是什么？ 使用它来做出编码决定有什么风险？
让我补充一点：我希望能够在这里用标准的准确报价来回答这个问题，因此我想发布立即可用的链接，而cplusplus.com本来就是我select的网站。这个问题。
更新：已经有了很多很好的回应，我已经认真地改变了我对cplusplus.com的看法。 我想在这里列出一些select结果。 随意build议更多（并保持发布答案）。
截至2011年6月29日：
- 一些algorithm的错误描述（例如
remove）。 - 有关函数行为的信息有时是不正确的（
atoi），没有提到特殊情况（strncpy），或者忽略了重要信息（迭代器失效）。 - 示例包含不推荐使用的代码（#include style）。
- 不明确的术语对学习者和普通社区（“STL”，“编译器”与“工具链”）都是有害的。
-
typeid关键字的错误和误导性描述。
编辑：从这个答案写入已经修复了std::remove文档。 同样的事情适用于list::remove 。
让我给你一个例子，告诉你如何cpluscplus.com可以弄错。
考虑<algorithm> std::remove函数。
事实是， std::remove不会从容器中删除项目。 它是因为std::remove只与一对迭代器一起工作，并不知道任何有关容器实际上包含的项目。 事实上， std::remove不可能知道底层容器，因为从一对迭代器中找不到迭代器所属的容器是不可能的。 所以std::remove并没有真的删除这些项目， 只是因为它不能 。 实际上从容器中删除项目的唯一方法是调用该容器上的成员函数。
所以，如果你想删除的项目，然后使用擦除删除成语 ：
v.erase(std::remove(v.begin(), v.end(), 10), v.end());
但cplusplus.com提供了关于std::remove 不正确的信息。 它说
注意，这个函数不会改变新的结尾的元素，这些元素保持旧的值 ，并且仍然可以访问 。
这是不正确的。 范围[new_end, old_end)的迭代器仍然是可解引用的，但这并不意味着它们保留旧值并仍然可以访问。 他们是不明确的。
同样， cplusplus.com提供了有关list::remove 错误信息。 它说 ，
请注意，全局algorithm函数remove， 具有类似的行为，但在两个迭代器之间运行。
这是完全错误的。 全局删除即std::remove与list::remove并不相似，正如我们所看到的，前者并不真正从容器中删除项目， 因为它不能 ，而后者（成员函数） 确实会删除项目， 因为它可以 。
这个答案是从我的另一个答案复制在下面的主题，几乎没有修改：
- STL删除不能按预期工作？
注意：由于我刚刚在上面的主题中回答了这个问题，所以我记得。 过去两年我遇到很多错误，我不记得了。 如果我再次遇到，我可能会再增加几个。
我打算提出一个相反的意见。 在cplusplus.com上有很多很好的信息。 select它死亡，是的，当然它有问题，但什么网站没有？ 当然不是这个网站 。 住在玻璃房子的人不应该扔石头。 这里也有很多错误的信息。 有被接受的答案是错误的，低估的答案（一些否定！）是正确的。
与cplusplus.com的一个问题是，它是一个封闭的网站; 大多数提到的其他参考站点也是如此。 这与Stack Overflow这样的社区开发站点的谷物背道而驰。 获得可信编辑的能力并不需要太长的时间，甚至最新的新手也可以很容易地提出改进build议。 与cplusplus.com比较一下。 如果你不是他们的员工，你永远是新手。 即使您是WG21的关键成员，如果您在该网站的某处发现错误，您也必须通过电子邮件报告机制。 诅咒！
一个解决scheme将是我们在这个网站上开发我们自己的C ++参考。 这将需要相当多的工作。 我们必须小心不要太迂腐/太技术; 很显然，cplusplus.com至less雇佣了一些技术编辑，让书呆子们不受困扰。 我们必须保持信息的组织良好; 这里的常见问题没有很好的组织。 我们也必须非常小心，不要直接从标准中喷出太多东西; 那是非法的
http://www.cplusplus.com/reference/clibrary/cstring/strncpy/
没有提到“如果在重叠的对象之间进行复制，行为是不确定的”。 （在C89标准中是4.11.2.4，我没有C90的拷贝，这是C ++ 03实际所指的，但是它们应该只在页面编号等方面有所不同）。
cplusplus.com提供的文档通常不正确或不完整。
一旦这样的例子，在cplusplus.com上的atoi文档。
的atoi
在使用函数时没有提及未定义的行为 ，
按照标准“ 如果string的数字值不能用int表示，那么行为是不确定的 ”。
但是cplusplus.com文档只是声明“ 如果正确的值超出了可表示值的范围，则返回INT_MAX或INT_MIN ”。
这纯粹是不正确的。
cplusplus.com上给出的许多示例源代码都是不正确的。
许多正在查找这些参考文献的新手都会导致出现ballant错误。
举一个例子：
编辑：我以前引用的例子是不正确的。
std::pair<T1,T2>::operator==的文档说明了这两个元素是否相等。 std::pair<T1,T2>::operator<的文档说第二个元素只有在第一个元素相等时才被考虑。
两种情况都出现“平等”一词。 然而，只有在第一种情况下才真正意味着T::operator== 。 在第二种情况下，等同的意思!(a.first<b.first || b.first<a.first)
type_info的文档尝试首先解释typeid ，但是失败：
typeid可以直接应用于types，在这种情况下返回它的信息; 或者对象，在这种情况下，它返回关于对象types的信息。
当typeid被应用于一个多态类types的对象（一个声明或inheritance一个虚函数的类）的解引用指针时，它将考虑它的dynamictypes（即派生最多的对象的types）。
现在第二段已经不同意了第一段。 在typeid(*ptr) ， typeid应用于expression式。 这是相当重要的，因为static和dynamictypes的概念只有在expression的上下文中才有意义，而不是对象。 它也错过了像typeid(foo()) 。
而且，第二段省略了引用。 它们也可以具有不同于它们引用的对象的dynamictypes的静态types。
