A
has no way of knowing thatkey
refers to the thing it's about to destroy.
Embora isso seja verdade, A
sabe o seguinte:
-
Seu objetivo é destruir algo .
-
É preciso um parâmetro que é exatamente do mesmo tipo da coisa que ele irá destruir.
Dado estes fatos, é possível que A
destrua seu próprio parâmetro se tomar o parâmetro como um ponteiro / referência. Este não é o único lugar em C ++ onde tais considerações precisam ser abordadas.
Essa situação é semelhante a como a natureza de um operador% de atribuição de operator=
significa que você precisa se preocupar com atribuição automática. Essa é uma possibilidade porque o tipo de this
e o tipo do parâmetro de referência são os mesmos.
Deve-se notar que isso é apenas problemático porque A
depois pretende usar o parâmetro key
após remover a entrada. Se isso não acontecesse, estaria tudo bem. Claro, então fica fácil ter tudo funcionando perfeitamente, então alguém altera A
para usar key
depois de ter sido potencialmente destruído.
Esse seria um bom lugar para um comentário.
Is there some rule we failed to follow?
Em C ++, você não pode operar sob a suposição de que, se seguir cegamente um conjunto de regras, seu código será 100% seguro. Não podemos ter regras para tudo .
Considere o ponto 2 acima. A
poderia ter tomado algum parâmetro de um tipo diferente da chave, mas o próprio objeto poderia ser um sub-objeto de uma chave no mapa. Em C ++ 14, find
pode ter um tipo diferente do tipo de chave, desde que haja uma comparação válida entre eles. Então, se você fizer m.erase(m.find(key))
, você pode destruir o parâmetro mesmo que o tipo do parâmetro não seja do tipo de chave.
Assim, uma regra como "se o tipo de parâmetro e o tipo de chave forem os mesmos, use-os por valor" não salvará você. Você precisaria de mais informações do que apenas isso.
Em última análise, você precisa prestar atenção aos seus casos de uso específicos e exercer um julgamento informado pela experiência.