Qual é o problema? cplusplus.com?
Há 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 carga curtos e exemplos de uso, e tenho encontrado cplusplus.com muito útil. No entanto, tenho ouvido opiniões negativas sobre esse site frequentemente aqui, por isso, gostaria de ser específico:
Quais são os erros, equívocos ou maus conselhos dados por cplusplus.com? quais são os riscos de usá-lo para tomar decisões de codificação?Deixe-me adicionar este ponto: eu quero ser capaz de responder a perguntas aqui sobre assim com citações precisas do padrão, e assim eu gostaria de postar links imediatamente utilizáveis, e cplusplus.com teria sido meu local de escolha não era para este problema.
6 answers
Editar: a documentação para std::remove foi corrigida desde que esta resposta foi escrita. A mesma coisa se aplica a list::remove.
Considere std::remove a função de <algorithm>.
O facto é questd::remove não remove o item do contentor. É porque std::remove trabalha apenas com um par de iteradores e não sabe nada sobre o recipiente que realmente contém os itens. Na verdade, é ... não é possível para std::remove conhecer o recipiente subjacente, porque não há maneira de ele ir de um par de iteradores para descobrir sobre o recipiente a que os iteradores pertencem. Então std::remove realmente não remove os itens, simplesmente porque não pode. A única maneira de de facto remover um item de um contentor é invocar uma função membro nesse contentor.
Se quiser remover os itens, então use apagar-remover o idioma:
v.erase(std::remove(v.begin(), v.end(), 10), v.end());
Mas cplusplus.com dá informações incorrectas sobre std::remove. Diz:
O que não está correcto. O iterador na escalaRepare que esta função não altera OS Elementos depois do novo fim, que mantêm os seus valores antigos e são ainda acessíveis.
[new_end, old_end) ainda é dereferenciável, mas isso não significa que eles mantenham os valores antigos e ainda estejam acessíveis.{[29] } eles são especificado.
Da mesma forma, cplusplus.com dá informações incorrectas também sobre list::remove. Diz:,
O que é completamente errado. A remoção global a saberObserve que uma função de algoritmo global, remove, existe com um comportamento similar mas operando entre dois iteradores.
std::remove não é semelhante a list::remove, Como vimos que o primeiro não remove realmente Os itens do recipiente porque ele não pode , enquanto que este último (a função de membro) realmente remove {[19] } Os itens porque pode .
Esta resposta é copiada da minha outra resposta no seguinte tópico, com pouca modificação:
Nota: desde que me deparei com isso recentemente, quando eu estava respondendo no tópico acima, eu me lembro. Há muitos erros com que me deparei nos últimos dois anos., que não me lembro. Posso acrescentar mais alguns mais tarde, se voltar a encontrar-me.
Um problema com cplusplus.com is que é um local fechado; o mesmo vale para a maioria dos outros sites de referência mencionados. Isto vai contra o grão de um site desenvolvido pela comunidade, como o fluxo de pilha. Adquirir a capacidade de fazer edições confiáveis não leva tanto tempo, e mesmo o mais novo dos novatos pode facilmente fazer sugestões para melhoria. Compare isso com cplusplus.com. você é um novato perpétuo se você não está em sua equipe. Mesmo se você é um membro chave do WG21, você tem que passar por seu mecanismo de relatório de E-mail se vês um insecto algures naquele site. Anátema!
Uma solução seria para nós neste site desenvolver a nossa própria referência c++. Seria preciso muito trabalho. Temos de ter cuidado para não sermos demasiado pedantes / demasiado técnicos; é óbvio que cplusplus.com emprega pelo menos alguns editores técnicos que mantêm os pedantes afastados. Teríamos que manter a informação bem organizada; as FAQ aqui não estão bem organizadas. Também teríamos de ter muito cuidado para não cuspir demasiado directamente do padrão, isso é ilegal.
Http://www.cplusplus.com/reference/clibrary/cstring/strncpy/
Falha em mencionar que " se a cópia ocorre entre objetos que se sobrepõem, o comportamento é indefinido."(4.11.2.4 in the C89 standard. Eu não tenho uma cópia para a mão de C90, que é o que C++03 realmente se refere, mas eles devem diferir apenas em coisas como numeração de páginas.)
a documentação fornecida por cplusplus.com é muitas vezes incorreto ou incompleto.
Uma vez que este exemplo seja, a documentação atoi sobre cplusplus.com.
Atoi
Na seção Return, não há menção sobre 0 Valor return se nenhuma conversão pode ser realizada durante a utilização da função.
Cplusplus.com regresso a secção diz "...Se o valor convertido estaria fora da Gama de valores representáveis por um int, causa um comportamento indefinido."
Isto está correcto, de acordo com a norma "Se o valor numérico da cadeia de caracteres não puder ser representado em int, então o comportamento é indefinido".
No entanto, a secção não está completa, uma vez que não menciona 0 como valor de retorno, o que pode ser enganador. A frase "...nenhuma conversão é realizada e zero é devolvido."é encontrado antes na descrição parágrafo, mas é essencial tê-lo na seção Return.
Muitos dos códigos-fonte da amostra indicados em cplusplus.com estão incorrectos.
Muitos dos novatos que olham para estas referências são levados a fazer erros ballant.
Para citar um exemplo:
Editar: o exemplo que citei anteriormente estava incorrecto.
A documentação para type_info tenta explicar typeid primeiro, mas falha:
O segundo parágrafo já discorda do primeiro. EmO Typeid pode ser aplicado directamente no tipos, caso em que devolve o seu informação; ou a objectos, nos quais caso devolva informações sobre a tipo do objecto.
Quando o typeid é aplicado a ponteiro deslocado para um objecto de um tipo de classe polimórfica (Classe a) declarar ou herdar um virtual função), considera a sua dinâmica tipo (ou seja, o tipo do mais objeto derivado).
typeid(*ptr), typeid é aplicado a uma expressão. Isto é bastante essencial, uma vez que a noção de tipos static e dynamic só faz sentido no contexto da expressão, não dos objectos. Também falha casos como typeid(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 referenciam.
A documentação de std::pair<T1,T2>::operator== diz que ambos os elementos são testados para a 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 em ambos os casos. No entanto, só no primeiro caso isso realmente significa T::operator==. No segundo caso, equal means !(a.first<b.first || b.first<a.first)