O que há de errado com cplusplus.com?

Talvez esse não seja um fórum perfeitamente adequado para essa pergunta, mas deixe-me tentar, com o risco de ser afastado.

Existem várias referências para a biblioteca padrão C ++, incluindo o inestimável padrão ISO, MSDN , IBM , cppreference e cplusplus . Pessoalmente, ao escrever C ++, preciso de uma referência que tenha acesso aleatório rápido, tempos de carregamento curtos e exemplos de uso, e tenho achado o cplusplus.com bastante útil. No entanto, tenho ouvido opiniões negativas sobre esse site frequentemente aqui no SO, então gostaria de ser mais específico:

Quais são os erros, conceitos errados ou conselhos ruins dados pelo cplusplus.com? Quais são os riscos de usá-lo para tomar decisões de codificação?

Deixe-me acrescentar este ponto: quero poder responder perguntas aqui no SO com aspas precisas do padrão e, portanto, gostaria de postar links imediatamente utilizáveis, e cplusplus.com teria sido o meu site preferido se não fosse por esse assunto.

Editar: a documentação para std::removefoi corrigida desde que esta resposta foi escrita. A mesma coisa se aplica a list::remove.

Deixe-me dar um exemplo para mostrar como o cpluscplus.com pode errar.

Considere a std::removefunção de <algorithm>.

O fato é que std::removenão remove o item do contêiner. É porque std::removefunciona apenas com um par de iteradores e não sabe nada sobre o contêiner que realmente contém os itens. De fato, não é possível std::removeconhecer o contêiner subjacente, porque não há como ir de um par de iteradores para descobrir sobre o contêiner ao qual os iteradores pertencem. Então std::remove, realmente não remove os itens, simplesmente porque não pode . A única maneira de realmente remover um item de um contêiner é invocar uma função de membro nesse contêiner.

Portanto, se você deseja remover os itens, use Erase-Remove Idiom :

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

Mas cplusplus.comfornece informações incorretas sobre std::remove. Diz

Observe que essa função não altera os elementos além do novo fim, que mantêm seus valores antigos e ainda estão acessíveis .

o que não está correto. O iterador no intervalo [new_end, old_end)ainda é desreferenciável, mas isso NÃO significa que eles mantêm os valores antigos e ainda estão acessíveis. Eles não são especificados.

Da mesma forma, também cplusplus.comfornece informações incorretaslist::remove . Ele diz ,

Observe que uma função de algoritmo global, remove, existe com um comportamento semelhante, mas operando entre dois iteradores.

o que está completamente errado. A remoção global, ou std::removeseja, não é semelhante a list::remove, como vimos que o antigo NÃO remove realmente os itens do contêiner porque não pode , enquanto o último (a função de membro) remove os itens porque pode .

Esta resposta é copiada da minha outra resposta no tópico a seguir, com poucas modificações:

• A remoção do STL não funciona como esperado?

Nota: Desde que me deparei com isso recentemente, quando estava respondendo no tópico acima, lembro-me dele. Existem muitos erros que encontrei nos últimos dois anos, dos quais não me lembro. Posso acrescentar mais alguns depois, se me deparar novamente.

Vou oferecer uma opinião um pouco ao contrário. Há muitas informações boas em cplusplus.com. Escolha até a morte e, sim, é claro que tem seus problemas, mas que site não? Certamente não este site . Pessoas que vivem em casas de vidro não devem atirar pedras. Também há muita desinformação aqui. Existem respostas aceitas que são totalmente erradas, com respostas reduzidas (algumas negativas!) Que são exatamente corretas.

Um problema do cplusplus.com é que ele é um site fechado; o mesmo vale para a maioria dos outros sites de referência mencionados. Isso vai de encontro a um site desenvolvido pela comunidade, como o Stack Overflow. Adquirir a capacidade de fazer edições confiáveis ​​não leva tanto tempo, e mesmo os novatos mais novos podem facilmente fazer sugestões de aprimoramento. Compare isso com cplusplus.com. Você é um novato perpétuo se não estiver na equipe deles. Mesmo se você for um membro importante do WG21, precisará passar pelo mecanismo de relatório por e-mail se encontrar um bug em algum lugar desse site. Anátema!

Neste site, seria uma solução desenvolver nossa própria referência C ++. Isso levaria um pouco de trabalho. Teríamos que ter cuidado para não sermos muito pedantes / técnicos; é óbvio que o cplusplus.com emprega pelo menos alguns editores técnicos que mantêm os pedantes afastados. Teríamos que manter as informações bem organizadas; as perguntas frequentes aqui não são bem organizadas. Também teríamos que ter muito cuidado para não jorrar muito diretamente do padrão; isso é ilegal.

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

Não menciona que "Se a cópia ocorre entre objetos que se sobrepõem, o comportamento é indefinido". (4.11.2.4 no padrão C89. Não tenho uma cópia em mãos do C90, que é o que C ++ 03 realmente se refere, mas eles devem diferir apenas em itens como numeração de páginas.)

A documentação fornecida pelo cplusplus.com geralmente está incorreta ou incompleta.

Uma vez que esse exemplo seja, a atoidocumentação em cplusplus.com.

atoi
Na seção Return, não há menção sobre o valor de retorno 0 se nenhuma conversão puder ser executada enquanto estiver usando a função.

A seção de retorno do cplusplus.com declara "... Se o valor convertido estiver fora da faixa de valores representáveis ​​por um int, ele causará um comportamento indefinido."

Isso está correto, conforme o padrão " Se o valor numérico da sequência não puder ser representado em int, o comportamento será indefinido ".

No entanto, a seção não está cheia, pois não menciona 0 como valor de retorno, o que pode ser enganoso. A frase "... nenhuma conversão é executada e zero é retornado". é atendido antes no parágrafo de descrição, mas é essencial tê-lo na seção Retornar .

Muitos dos códigos-fonte de amostra fornecidos no cplusplus.com estão incorretos.
Muitos dos novatos que procuram essas referências são levados a cometer erros redundantes.

Para citar um exemplo:

EDIT: O exemplo que citei anteriormente estava incorreto.

A documentação para type_infotenta explicar typeidprimeiro, mas falha:

typeid pode ser aplicado diretamente aos tipos; nesse caso, ele retorna suas informações; Ou para objetos; nesse caso, ele retorna informações sobre o tipo do objeto.

Quando typeid é aplicado a um ponteiro não referenciado para um objeto de um tipo de classe polimórfica (uma classe que declara ou herda uma função virtual), ele considera seu tipo dinâmico (ou seja, o tipo do objeto mais derivado).

Agora, o segundo parágrafo já discorda do primeiro. In typeid(*ptr), typeidé aplicado a uma expressão. Isso é bastante essencial, uma vez que a noção statice os dynamictipos só fazem sentido no contexto da expressão, não nos objetos. Ele também perde casos comotypeid(foo()) .

Além disso, o segundo parágrafo omite referências. Eles também podem ter tipos estáticos diferentes do tipo dinâmico do objeto que fazem referência.

A documentação std::pair<T1,T2>::operator==diz que ambos os elementos são testados quanto à igualdade. A documentação de std::pair<T1,T2>::operator<diz que os segundos elementos são considerados apenas se os primeiros elementos forem iguais.

A palavra "igual" aparece nos dois casos. No entanto, somente no primeiro caso isso realmente significa T::operator==. No segundo caso, médias iguais!(a.first<b.first || b.first<a.first)