cplusplus.com有什么问题?

Ker*_* SB 192 c++

对于这个问题,这可能不是一个非常合适的论坛,但是让我试一试,冒着被搬走的风险.

C++标准库有几个参考,包括非常有价值的ISO标准,MSDN,IBM,cppreferencecplusplus.就个人而言,在编写C++时,我需要一个具有快速随机访问,短加载时间和使用示例的引用,并且我一直在发现cplusplus.com非常有用.但是,我一直在SO上听到关于该网站的负面看法,所以我想具体说明:

cplusplus.com提供的错误,误解或错误建议有哪些?使用它来做出编码决策有哪些风险?

让我补充一点:我希望能够通过标准的准确报价在这里回答问题,因此我想发布可立即使用的链接,而cplusplus.com将是我选择的网站,如果不是这个问题.

Naw*_*waz 70

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

让我举个例子来告诉你cpluscplus.com如何弄错.

考虑std::remove来自的功能<algorithm>.

事实是,std::remove不会从容器中删除该项目.它因为std::remove只使用一对迭代器而且对实际包含项目的容器一无所知.事实上,不可能std::remove知道底层容器,因为它无法从一对迭代器中发现迭代器所属的容器.所以std::remove不能真正删除这些项目,因为它不能.实际从容器中删除项目的唯一方法在该容器上调用成员函数.

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

 v.erase(std::remove(v.begin(), v.end(), 10), v.end()); 
Run Code Online (Sandbox Code Playgroud)

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

请注意,此函数不会更改通过新结尾的元素,这些元素保留旧值仍可访问.

这是不正确的.范围内的迭代器[new_end, old_end)仍然是可解除引用的,但这并不意味着它们保留旧值并且仍可访问.他们没有具体说明.


同样,也cplusplus.com提供了不正确的信息list::remove.它说,

请注意,全局算法函数remove 具有类似的行为,但在两个迭代器之间运行.

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

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

注意:自从我最近在回答上述主题时遇到过这个问题,我记得它.我在过去两年中遇到过很多错误,我不记得了.如果我再次遇到,我可能会在以后添加更多.

  • @Steve:你说"类似"是有争议的.如果"相似"这个词是有争议的,那么它就会告诉这个词不是正确的词,在解释`std :: remove`和`list :: remove`的行为时应该避免,因为*解释*应尽可能清楚,不应另外解释. (5认同)
  • @Alexander:`list :: remove`确实从容器中删除了元素.但是`std :: remove`不会从容器中删除元素.我**不能**说他们的行为"相似". (4认同)
  • "类似"是有争议的,因为观察两个不同的操作是否相似是一个问题.cplusplus.com是否应该提供伪装成文档的意见也是有争议的.但无论如何,"保持他们的旧价值"是一个不可原谅的错误,它只是表明cplusplus描述不是基于标准. (3认同)
  • 好抓!这是我正在寻找的事情的一个很好的例子. (2认同)

Dav*_*men 33

我将略微提出相反的意见.cplusplus.com上有很多很好的信息.选择它去死,是的,当然它有它的问题,但是什么网站没有?当然不是这个网站.住在玻璃房子里的人不应该扔石头.这里也有很多错误的信息.已经接受的答案是完全错误的,低估的答案(有些是负面的!)是正确的.

cplusplus.com的一个问题是它是一个封闭的网站; 大多数提到的其他参考站点也是如此.这与社交开发的网站(例如Stack Overflow)不同.获得进行可信编辑的能力并不需要那么长时间,即使是最新的新手也可以轻松地提出改进建议.与cplusplus.com相比.如果你不在他们的工作人员,你是一个永久的新手.即使您是WG21的关键成员,如果您在该网站的某个地方看到错误,也必须通过他们的电子邮件报告机制.诅咒!

我们将在此站点为您提供解决方案来开发我们自己的C++参考.这需要相当多的工作.我们必须小心,不要太迂腐/太技术; 很明显,cplusplus.com雇佣了至少一些技术编辑来保持这些学员.我们必须保持信息井井有条; 这里的FAQ没有很好的组织.我们还必须非常小心,不要直接从标准上喷出太多东西; 那是非法的.

  • 哇!我看到的恰恰相反.我停止了经常使用旧的cppreference.com,因为我发现很难遍历并写得不好.新的cppreference.com似乎是一个无广告,基于社区的网站,完全符合我在上一段中的建议. (10认同)
  • "住在玻璃房子里的人不应该扔石头." SO并不声称(部分)是C++的库引用,如http://www.cplusplus.com/reference/所做的那样.当人们在这里提出要求时,他们引用标准来支持他们,或者如果他们没有,那么其他人就会出现并填写.如果他们错了,你可以看到他们的工作.如果cplusplus.com错了,你只是编写了一些C++实现失败的代码,而不是作者用来生成"其元素的详细描述"的代码.问题是cplusplus.com是非正式的,但写得看起来很正式. (9认同)
  • 我曾经经常使用旧的cppreference.com,但是现在他们已经将它改成了wiki-ish(每个人都可以编辑吗?)......我不再喜欢它了.我发现,很难看到重要的信息.它只是缺乏我从cplusplus.com获得的即时满足感.我认为. (5认同)
  • SO是非正式的,写作看起来非正式.现在,如果cplusplus.com并非打算成为准确的文档/参考资料,而且我在某个地方错过了免责声明,那么就假设有任何一块石头被投掷给使用它的人而不是网站本身.但问题是,仅仅因为cplusplus.com对C++函数说了些什么并不意味着它是真的,如果你打算将它用作快速参考,那么值得知道.我用它来查找函数签名,但从来没有解决我的代码是否符合的问题. (4认同)

Ste*_*sop 14

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

未提及"如果在重叠的对象之间进行复制,则行为未定义." (C89标准中的4.11.2.4.我没有C90的副本,这是C++ 03实际引用的内容,但它们应该只在页面编号等方面有所区别.)

  • 他们提到"目的地和来源不应重叠". (5认同)
  • @Sniper“不得重叠”与“行为未定义”不同。您的评论实际上揭示了 cplusplus.com 微妙而普遍的缺陷之一 - 听起来不错,但实际上是不正确的。 (2认同)
  • @AndrewHenle实际上,使用术语“不得”来表示未定义的行为是很常见的。事实上,C 标准本身[就是这样做的](https://wiki.sei.cmu.edu/confluence/display/c/MSC15-C.+Do+not+depend+on+undefined+behavior#:~:文本=如果%20a%20%22应%22%20或%20%22,任何%20显式%20定义%20of%20行为。)。抱歉,我没有实际的标准,只是二手资料。 (2认同)

Alo*_*ave 8

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

这样的例子就是atoicplusplus.com上的文档.

atoi
在返回部分,如果在使用该功能时无法执行转换,则不会提及0返回值.

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

这是正确的,根据标准" 如果字符串的数值不能用int表示,那么行为是未定义的 ".

但是该部分并不完整,因为它没有提到0作为返回值,这可能会产生误导.短语"......没有执行转换,返回零." 在描述段落之前已经满足,但必须在Return部分中使用它.

cplusplus.com上提供的许多示例源代码都不正确.
许多关注这些参考文献的新手都会导致出现错误.

举个例子:

编辑:我之前引用的例子不正确.

  • 或许是bal气 - >明目张胆?然而,ballant是法语中的"悬空",可能适用于涉及指针的错误. (5认同)
  • 您声明“cplusplus.com 上提供的许多示例源代码都不正确。” 然后删除了“我之前引用的示例不正确”的示例。- 那你为什么要删除这个例子?:) (2认同)