c++标准库有很多参考资料，包括无价的ISO标准、MSDN、IBM、cppreference和cplusplus。就我个人而言，在编写c++时，我需要一个具有快速随机访问、短加载时间和使用示例的参考，而我发现cplusplus.com非常有用。然而，我经常在SO网站上听到关于该网站的负面意见，所以我想具体说明:
cplusplus.com给出的错误、误解或坏建议是什么?使用它来做编码决策的风险是什么?
我希望能够用准确的标准引用来回答关于SO的问题，因此我想发布立即可用的链接，如果不是因为这个问题，cplusplus.com将是我选择的网站。
编辑:std::remove的文档已经修复，因为这个答案是写的。同样的事情也适用于list::remove。
让我给你一个例子来说明cpluscplus.com是如何出错的。
考虑std::remove函数从<算法>。
The fact is thatstd::remove doesn't remove the item from the container. Its because std::remove works with a pair of iterators only and does not know anything about the container which actually contains the items. In fact, it's not possible for std::remove to know the underlying container, because there is no way it can go from a pair of iterators to discover about the container to which the iterators belong. So std::remove doesn't really remove the items, simply because it cannot. The only way to actually remove an item from a container is to invoke a member function on that container.
所以如果你想删除项目，那么使用擦除-删除习语:
v.erase(std::remove(v.begin(), v.end(), 10), v.end());
但是cplusplus.com给出了关于std::remove的错误信息。它说
注意，这个函数不会改变new结束后的元素，这些元素保持旧值，仍然可以访问。
这是不正确的。[new_end, old_end)范围内的迭代器仍然是可解引用的，但这并不意味着它们保持旧值并且仍然可以访问。他们没有具体说明。
类似地，cplusplus.com也给出了关于list::remove的错误信息。它说,
请注意，存在一个全局算法函数remove，其行为类似，但操作在两个迭代器之间。
这是完全错误的。全局remove(即std::remove)与list::remove不相似，正如我们所看到的，前者不会真正从容器中删除项，因为它不能，而后者(成员函数)确实会删除项，因为它可以。
这个答案是从我在以下主题的另一个答案中复制过来的，有一点修改:
STL删除不像预期的那样工作?
注:因为我最近在回复上面的话题时遇到了这个问题，所以我记得它。在过去的两年里，我遇到了很多错误，我不记得了。如果以后再遇到的话，我可能会再补充一些。
http://www.cplusplus.com/reference/clibrary/cstring/strncpy/
没有提到“如果复制发生在重叠的对象之间，行为是未定义的。”(C89标准中的4.11.2.4。我手头没有C90的副本，这是c++ 03实际上指的，但它们应该只是在诸如页码之类的东西上有所不同。)
cplusplus.com提供的文档通常是不正确或不完整的。
一旦这样的例子是，在cplusplus.com上的atoi文档。
atoi 在Return部分中，如果在使用函数时不能执行转换，则没有提到返回值为0。
返回节声明“…如果转换后的值超出了int可表示值的范围，则会导致未定义的行为。”
这是正确的，根据标准“如果字符串的数值不能用int表示，那么行为是未定义的”。
然而，由于没有提到0作为返回值，因此该部分不是满的，这可能会产生误导。短语“…”不执行任何转换并返回零。”在描述段之前已经满足，但在Return部分中有它是必要的。
在cplusplus.com上给出的许多样例源代码是不正确的。 许多新人在参考这些参考资料的时候都犯了严重的错误。
举个例子:
编辑:我之前引用的例子是不正确的。
我要提出一个略微相反的观点。在cplusplus.com上有很多好的信息。把它挑到死，是的，当然它有它的问题，但哪个网站没有呢?当然不是这个网站。住在玻璃房子里的人不应该扔石头。这里也有很多错误信息。有些公认的答案是完全错误的，有些被否决的答案(有些是否定的!)是完全正确的。
One issue with cplusplus.com is is that it is a closed site; the same goes for most the other reference sites mentioned. This goes against the grain of a community-developed site such as Stack Overflow. Acquiring the ability to make trusted edits doesn't take all that long, and even the newest of newbies can easily make suggestions for improvement. Compare that to cplusplus.com. You are a perpetual newbie if you aren't on their staff. Even if you are a key member of WG21, you have to go through their email report mechanism if you see a bug somewhere in that site. Anathema!
一个解决方案是我们在这个网站上开发自己的c++参考。这需要相当多的工作。我们必须小心不要太迂腐/太专业;很明显，cplusplus.com至少雇佣了一些技术编辑，使学究们远离困境。我们必须让信息井然有序;这里的常见问题没有很好的组织。我们还必须非常小心，不要直接从标准中喷出太多;这是非法的。
type_info的文档试图先解释typeid，但失败了:
Typeid可以直接应用于 类型，在这种情况下，它返回它的 信息;或者物体，在其中 的情况下返回信息 对象类型。 当typeid应用于 对象的解引用指针 多态类类型(一个类 声明或继承一个虚拟对象 函数)，它认为它是动态的 类型(即最 派生的对象)。
现在第二段已经和第一段不一致了。在typeid(*ptr)中，typeid应用于表达式。这是相当重要的，因为静态和动态类型的概念只在表达式上下文中有意义，而不是在对象上下文中。它还会遗漏typeid(foo())这样的情况。
此外，第二段省略了引用。它们也可以具有不同于所引用对象的动态类型的静态类型。
std::pair<T1,T2>::operator==的文档说明两个元素都进行了相等性测试。std::pair<T1,T2>::operator<的文档表明，只有当第一个元素相等时才考虑第二个元素。
“equal”这个词在两种情况下都出现了。然而，只有在第一种情况下，它才真正意味着T::operator==。在第二种情况下，相等意味着!(a.first<b。|| b.first<a.first)
