C++ cplusplus.com 有什么问题？

What's wrong with cplusplus.com?

提问by Kerrek SB

This is perhaps not a perfectly suitable forum for this question, but let me give it a shot, at the risk of being moved away.

对于这个问题，这可能不是一个完全合适的论坛，但让我试一试，冒着被移走的风险。

There are several references for the C++ standard library, including the invaluable ISO standard, MSDN, IBM, cppreference, and cplusplus. Personally, when writing C++ I need a reference that has quick random access, short load times and usage examples, and I've been finding cplusplus.com pretty useful. However, I've been hearing negative opinions about that website frequently here on SO, so I would like to get specific:

C++ 标准库有多个参考资料，包括无价的 ISO 标准、MSDN、IBM、cppreference和cplusplus。就我个人而言，在编写 C++ 时，我需要一个具有快速随机访问、短加载时间和使用示例的参考，而且我发现 cplusplus.com 非常有用。但是，我经常在 SO 上听到对该网站的负面评价，所以我想具体说明一下：

What are the errors, misconceptions or bad pieces of advice given by cplusplus.com? What are the risks of using it to make coding decisions?

cplusplus.com 给出的错误、误解或不好的建议是什么？使用它来做出编码决策有哪些风险？

Let me add this point: I want to be able to answer questions here on SO with accurate quotes of the standard, and thus I would like to post immediately-usable links, and cplusplus.com would have been my choice site were it not for this issue.

让我补充一点：我希望能够用准确的标准引用来回答 SO 上的问题，因此我想发布立即可用的链接，如果不是 cplusplus.com，我会选择它这个问题。

回答by Nawaz

Edit:Documentation for std::removehas been fixed since this answer was written. Same thing applies to list::remove.

编辑：std::remove自编写此答案以来，已修复文档。同样的事情适用于list::remove.

Let me give you an example to show you how cpluscplus.com can get it wrong.

让我举个例子来告诉你 cpluscplus.com 是如何出错的。

Consider std::removefunction from <algorithm>.

考虑std::remove来自 的函数<algorithm>。

The fact is thatstd::removedoesn't remove the item from the container. Its because std::removeworks 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::removeto 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::removedoesn't really remove the items, simply because it cannot. The only way to actuallyremove an item from a container is to invoke a member function on that container.

事实是这std::remove不会从容器中删除项目。这是因为仅std::remove适用于一对迭代器，并且对实际包含项目的容器一无所知。事实上，std::remove知道底层容器是不可能的，因为它无法从一对迭代器中发现迭代器所属的容器。所以std::remove并没有真正删除项目，仅仅是因为它不能。从容器中实际删除项目的唯一方法是调用该容器上的成员函数。

So if you want to remove the items, then use Erase-Remove Idiom:

因此，如果要删除项目，请使用Erase-Remove Idiom：

 v.erase(std::remove(v.begin(), v.end(), 10), v.end()); 

But cplusplus.comgives incorrectinformation about std::remove. It says

但是cplusplus.com给出了不正确的信息std::remove。它说

Notice that this function does not alterthe elements past the new end, which keep their old valuesand are still accessible.

请注意，此函数不会更改新端之后的元素，这些元素保留其旧值并且仍然可以访问。

which isn't correct. The iterator in the range [new_end, old_end)is still dereferenceable, but that does NOT mean that they keep the old values and are still accessible.They are unspecified.

这是不正确的。范围内的迭代器[new_end, old_end)仍然是可解引用的，但这并不意味着它们保留了旧值并且仍然可以访问。它们是未指定的。

---

---

Similarly, cplusplus.comgives incorrectinformation about list::removeas well. It says,

同样，cplusplus.com给出不正确的信息list::remove。它说，

Notice that a global algorithm function, remove, exists with a similar behaviorbut operating between two iterators.

请注意，全局算法函数 remove 存在类似行为，但在两个迭代器之间运行。

which is completely wrong. The global remove namely std::removeis not similar to list::remove, as we saw that the former does NOT really removethe items from the container because it cannot, whereas the latter (the member function) really does removethe items because it can.

这是完全错误的。全局 remove 即std::remove与 不相似list::remove，因为我们看到前者并没有真正从容器中删除项目，因为它不能，而后者（成员函数）确实删除了项目，因为它可以。

This answer is copied from my another answer in the following topic, with little modification:

这个答案是从我在以下主题中的另一个答案复制而来的，几乎没有修改：

• STL remove doesn't work as expected?

• STL 删除无法按预期工作？

Note:Since I came across this recently when I was replying in the above topic, I remember it. There are many errors which I've come across over the last two years, which I don't remember. I might add few more later, if I come across again.

注：由于我最近在回复上述主题时遇到了这个，所以我记住了。在过去的两年里，我遇到了很多错误，我不记得了。如果我再次遇到，我可能会在以后添加更多。

回答by David Hammen

I'm going to offer an opinion slightly to the contrary. There is lots of good information on cplusplus.com. Pick at it to death, and yes, of course it has its problems, but what site doesn't? Certainly not this site. People who live in glass houses shouldn't throw stones. There is a lot of misinformation here, too. There are accepted answers that are flat-out wrong, downvoted answers (some negative!) that are spot-on correct.

我将提供稍微相反的意见。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!

cplusplus.com 的一个问题是它是一个封闭站点。提到的大多数其他参考站点也是如此。这与 Stack Overflow 等社区开发站点的思路背道而驰。获得进行可信编辑的能力并不需要很长时间，即使是最新的新手也可以轻松提出改进建议。将其与 cplusplus.com 进行比较。如果您不在他们的员工中，您就是永远的新手。即使您是 WG21 的主要成员，如果您在该站点的某处看到错误，也必须通过他们的电子邮件报告机制。诅咒！

A solution would be for us at this site to develop our own C++ reference. This would take quite a bit of work. We'd have to be careful not to be too pedantic / too technical; it is obvious that cplusplus.com employs at least a few technical editors who keep the pedants at bay. We'd have to keep the information well-organized; the FAQ here are not well organized. We'd also have to be very careful not to spout too much directly from the standard; that's illegal.

一个解决方案是让我们在这个站点上开发我们自己的 C++ 参考。这将需要相当多的工作。我们必须小心不要太迂腐/太技术；很明显，cplusplus.com 至少雇佣了一些技术编辑来阻止学究。我们必须保持信息井井有条；这里的常见问题解答没有很好地组织。我们还必须非常小心，不要直接从标准中喷出太多东西；那是非法的。

回答by Steve Jessop

http://www.cplusplus.com/reference/clibrary/cstring/strncpy/

http://www.cplusplus.com/reference/clibrary/cstring/strncpy/

Fails to mention that "If copying takes place between objects that overlap, the behavior is undefined." (4.11.2.4 in the C89 standard. I don't have a copy to hand of C90, which is what C++03 actually refers to, but they are supposed to differ only in stuff like page numbering.)

没有提到“如果复制发生在重叠的对象之间，则行为未定义。” （C89 标准中的 4.11.2.4。我手头没有 C90 的副本，这正是 C++03 实际指的内容，但它们应该仅在页码之类的东西上有所不同。）

回答by Alok Save

The documentation given by cplusplus.com is often incorrect or incomplete.

cplusplus.com 提供的文档通常不正确或不完整。

Once such example is ,the atoidocumentation on cplusplus.com.

一旦这样的例子是，atoicplusplus.com 上的文档。

atoi
In Return section, there is no mentioning about 0 return value if no conversion can be performed while using the function.

atoi
在返回部分，没有提到如果在使用函数时不能进行转换，返回值是 0。

cplusplus.com Returnsection states "...If the converted value would be out of the range of representable values by an int, it causes undefined behavior."

cplusplus.com返回部分指出“...如果转换后的值超出 int 可表示值的范围，则会导致未定义的行为。”

This is correct, as per the standard "If the numeric value of the string can't be represented in int, then the behaviour is undefined".

这是正确的，按照标准“如果字符串的数值不能用 int 表示，则行为未定义”。

However the section is not full as it does not mention 0 as return value, which can be misleading. The phrase "...no conversion is performed and zero is returned." is met before in description paragraph, but it is essential to have it in Returnsection.

然而，该部分并不完整，因为它没有提到 0 作为返回值，这可能会产生误导。短语“...不执行转换并返回零”。之前在描述段落中遇到过，但在返回部分中有它是必不可少的。

Many of the sample source codes given on cplusplus.com are incorrect.
Many of the newbies looking up to these references are led to making ballant errors.

cplusplus.com 上提供的许多示例源代码是不正确的。
许多仰望这些参考文献的新手都导致了平衡错误。

To cite a example:

举个例子：

EDIT: The example I cited previously was incorrect.

编辑：我之前引用的例子是不正确的。

回答by MSalters

The documentation for type_infotries to explain typeidfirst, but fails:

type_info尝试首先解释的文档typeid，但失败了：

typeid can be applied directly to types, in which case it returns its information; Or to objects, in which case it returns information on the type of the object.

When typeid is applied to a dereferenced pointer to an object of a polymorphic class type (a class declaring or inheriting a virtual function), it considers its dynamic type (i.e., the type of the most derived object).

typeid 可以直接应用于类型，在这种情况下它返回其信息；或者到对象，在这种情况下，它返回有关对象类型的信息。

当 typeid 应用于指向多态类类型（声明或继承虚函数的类）的对象的解除引用指针时，它会考虑其动态类型（即最派生对象的类型）。

Now the second paragraph already disagrees with the first. In typeid(*ptr), typeidis applied to an expression. This is rather essential, since the notion of staticand dynamictypes only makes sense in the context of expression, not objects. It also misses cases like typeid(foo()).

现在第二段已经不同意第一段了。在typeid(*ptr),typeid应用于表达式。这是相当重要的，因为static和dynamic类型的概念仅在表达式的上下文中才有意义，而不是在对象的上下文中。它也错过了像typeid(foo()).

Furthermore, the second paragraph omits references. They too can have static types different from the dynamic type of the object they reference.

此外，第二段省略了引用。它们也可以具有不同于它们引用的对象的动态类型的静态类型。

回答by MSalters

The documentation of std::pair<T1,T2>::operator==says that both elements are tested for equality. The documentation of std::pair<T1,T2>::operator<says that the second elements are considered only if the first elements are equal.

的文档std::pair<T1,T2>::operator==说这两个元素都经过了相等性测试。的文档std::pair<T1,T2>::operator<说只有在第一个元素相等时才考虑第二个元素。

The word "equal" appears in both cases. Yet, only in the first case does it really mean T::operator==. In the second case, equal means !(a.first<b.first || b.first<a.first)

“平等”一词出现在这两种情况下。然而，只有在第一种情况下，它才真正意味着T::operator==. 在第二种情况下，相等意味着!(a.first<b.first || b.first<a.first)