¿Qué le pasa a cplusplus.com?

Tal vez este no sea un foro perfectamente adecuado para esta pregunta, pero permítanme intentarlo, a riesgo de ser alejado.

Hay varias referencias para la biblioteca estándar de C ++, incluido el invaluable estándar ISO, MSDN , IBM , cppreference y cplusplus . Personalmente, cuando escribo C ++, necesito una referencia que tenga acceso aleatorio rápido, tiempos de carga cortos y ejemplos de uso, y he encontrado que cplusplus.com es bastante útil. Sin embargo, he estado escuchando opiniones negativas sobre ese sitio web con frecuencia aquí en SO, por lo que me gustaría ser específico:

¿Cuáles son los errores, conceptos erróneos o malos consejos dados por cplusplus.com? ¿Cuáles son los riesgos de usarlo para tomar decisiones de codificación?

Permítanme agregar este punto: quiero poder responder preguntas aquí en SO con citas precisas del estándar, y por lo tanto me gustaría publicar enlaces de uso inmediato, y cplusplus.com habría sido mi sitio de elección si no fuera por este problema.

Editar: la documentación para std::removese ha corregido desde que se escribió esta respuesta. Lo mismo se aplica a list::remove.

Déjame darte un ejemplo para mostrarte cómo cpluscplus.com puede equivocarse.

Considerar std::remove función de <algorithm>.

El hecho es que std::removeno elimina el artículo del contenedor. Es porque std::removefunciona solo con un par de iteradores y no sabe nada sobre el contenedor que realmente contiene los elementos. De hecho, no es posible std::removeconocer el contenedor subyacente, porque no hay forma de que un par de iteradores pueda descubrir el contenedor al que pertenecen los iteradores. Entonces std::remove, realmente no elimina los elementos, simplemente porque no puede . La única forma de eliminar realmente un elemento de un contenedor es invocar una función miembro en ese contenedor.

Entonces, si desea eliminar los elementos, use Erase-Remove Idiom :

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

Pero cplusplus.comda información incorrecta sobre std::remove. Dice

Tenga en cuenta que esta función no altera los elementos más allá del nuevo final, que mantienen sus valores anteriores y aún son accesibles .

lo cual no es correcto El iterador en el rango [new_end, old_end)sigue siendo desreferenciable, pero eso NO significa que conserven los valores antiguos y aún sean accesibles. No están especificados.

Del mismo modo, cplusplus.comda información incorrecta sobre list::removetambién. Se dice ,

Observe que existe una función de algoritmo global, eliminar, con un comportamiento similar pero que opera entre dos iteradores.

lo cual está completamente mal. La eliminación global, a saber, std::removeno es similar a list::remove, ya que vimos que la primera NO elimina realmente los elementos del contenedor porque no puede , mientras que la segunda (la función miembro) realmente elimina los elementos porque sí puede .

Esta respuesta se copia de mi otra respuesta en el siguiente tema, con pocas modificaciones:

• ¿Eliminar STL no funciona como se esperaba?

Nota: desde que me encontré con esto recientemente cuando respondía al tema anterior, lo recuerdo. Hay muchos errores que he encontrado en los últimos dos años, que no recuerdo. Podría agregar algunos más más tarde, si me encuentro de nuevo.

Voy a ofrecer una opinión un poco al contrario. Hay mucha buena información en cplusplus.com. Míralo hasta la muerte y sí, por supuesto que tiene sus problemas, pero ¿qué sitio no? Ciertamente no este sitio . Las personas que viven en casas de cristal no deberían tirar piedras. Aquí también hay mucha información errónea. Hay respuestas aceptadas que son totalmente incorrectas, respuestas negativas (¡algunas negativas!) Que son correctas.

Un problema con cplusplus.com es que es un sitio cerrado; Lo mismo ocurre con la mayoría de los otros sitios de referencia mencionados. Esto va en contra de un sitio desarrollado por la comunidad, como Stack Overflow. Adquirir la capacidad de realizar ediciones de confianza no lleva mucho tiempo, e incluso los novatos más nuevos pueden hacer sugerencias de mejora fácilmente. Compare eso con cplusplus.com. Eres un novato perpetuo si no estás en su personal. Incluso si es un miembro clave de WG21, debe revisar su mecanismo de informe por correo electrónico si ve un error en algún lugar de ese sitio. ¡Anatema!

Una solución sería para nosotros en este sitio desarrollar nuestra propia referencia de C ++. Esto llevaría bastante trabajo. Tendríamos que tener cuidado de no ser demasiado pedantes / demasiado técnicos; Es obvio que cplusplus.com emplea al menos algunos editores técnicos que mantienen a raya a los pedantes. Tendríamos que mantener la información bien organizada; Las preguntas frecuentes aquí no están bien organizadas. También tendríamos que tener mucho cuidado de no soltar demasiado directamente del estándar; Eso es ilegal.

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

No menciona que "si la copia se realiza entre objetos que se superponen, el comportamiento no está definido". (4.11.2.4 en el estándar C89. No tengo una copia a mano de C90, que es a lo que realmente se refiere C ++ 03, pero se supone que difieren solo en cosas como la numeración de páginas).

La documentación proporcionada por cplusplus.com es a menudo incorrecta o incompleta.

Una vez que tal ejemplo es, la atoidocumentación en cplusplus.com.

atoi
En la sección Retorno, no se menciona el valor de retorno 0 si no se puede realizar la conversión mientras se usa la función.

La sección de retorno de cplusplus.com dice "... Si el valor convertido estaría fuera del rango de valores representables por un int, esto causa un comportamiento indefinido".

Esto es correcto, según el estándar " Si el valor numérico de la cadena no se puede representar en int, entonces el comportamiento es indefinido ".

Sin embargo, la sección no está llena ya que no menciona 0 como valor de retorno, lo que puede ser engañoso. La frase "... no se realiza ninguna conversión y se devuelve cero". se cumple antes en el párrafo de descripción, pero es esencial tenerlo en la sección Volver .

Muchos de los códigos fuente de muestra que figuran en cplusplus.com son incorrectos.
Muchos de los novatos que buscan estas referencias se ven obligados a cometer errores graves.

Para citar un ejemplo:

EDITAR: El ejemplo que cité anteriormente era incorrecto.

La documentación para type_infointenta explicar typeidprimero, pero falla:

typeid se puede aplicar directamente a los tipos, en cuyo caso devuelve su información; O a los objetos, en cuyo caso devuelve información sobre el tipo de objeto.

Cuando typeid se aplica a un puntero desreferenciado a un objeto de un tipo de clase polimórfica (una clase que declara o hereda una función virtual), considera su tipo dinámico (es decir, el tipo del objeto más derivado).

Ahora el segundo párrafo ya no está de acuerdo con el primero. En typeid(*ptr), typeidse aplica a una expresión. Esto es bastante esencial, ya que la noción de staticy dynamictipos solo tiene sentido en el contexto de la expresión, no en los objetos. También echa de menos casos comotypeid(foo()) .

Además, el segundo párrafo omite referencias. También pueden tener tipos estáticos diferentes del tipo dinámico del objeto al que hacen referencia.

La documentación de std::pair<T1,T2>::operator==dice que ambos elementos se prueban para la igualdad. La documentación de std::pair<T1,T2>::operator<dice que los segundos elementos se consideran solo si los primeros elementos son iguales.

La palabra "igual" aparece en ambos casos. Sin embargo, solo en el primer caso realmente significa T::operator==. En el segundo caso, igual significa!(a.first<b.first || b.first<a.first)