Em sua palestra no GoingNative 2013, Scott Meyers apontou questd::move não é garantia de que o código gerado irá realmente realizar um movimento.

Exemplo:

void foo(std::string x, const std::string y) {
  std::string x2 = std::move(x); // OK, will be moved
  std::string y2 = std::move(y); // compiles, but will be copied
}

Aqui, o construtor de movimento não pode ser aplicado, mas devido à resolução de sobrecarga, o construtor de cópia normal será usado. Essa opção de fallback pode ser crucial para compatibilidade com versões anteriores do código C ++ 98, mas no exemplo acima é mais provável que não seja o que o programador pretendia.

Existe uma maneira de reforçar que um construtor de movimento será chamado?

Por exemplo, suponha que você queira mover uma matriz enorme. Se o seu aplicativo realmente depende do Matrix a ser movido, seria ótimo receber imediatamente um erro de compilação se um movimento não for possível. (Caso contrário, o problema de desempenho pode passar facilmente pelos testes de unidade e você só descobrirá depois de alguns perfis.)

Vamos chamar este movimento garantidostrict_move. Eu gostaria de poder escrever código como este:

void bar(Matrix x, const Matrix y) {
  Matrix x2 = strict_move(x); // OK
  Matrix y2 = strict_move(y); // compile error
}

É possível?

Editar:

Obrigado pelas ótimas respostas! Houve alguns pedidos legítimos para esclarecer minha dúvida:

Devemosstrict_move falhar se a entrada for const?Devemosstrict_move falha se o resultado não levar a uma operação de movimentação real (mesmo que a cópia seja tão rápida quanto um movimento, por exemplo,const complex<double>)Ambos?

Minha idéia original foi muito vaga: eu considerei os exemplos de Scott Meyers bastante alarmantes, então me perguntei se é possível ter o compilador impedindo cópias não intencionais.

Scott Meyers mencionou em sua palestra que um aviso geral do compilador não é uma opção, pois resultaria em um grande número de falsos positivos. Em vez disso, quero comunicar ao compilador algo como "Tenho 100% de certeza de que isso sempre deve resultar em uma operação de movimentação e uma cópia é muito cara para esse tipo específico".

Assim, eu teria dito, sem rodeios, questrict_move deve falhar em ambos os casos. Enquanto isso, não tenho certeza do que seria melhor. Outros aspectos que eu não considereinoexcept.

Do meu lado, a semântica exata destrict_move estão abertos. Tudo o que ajuda a evitar alguns erros idiotas em tempo de compilação sem ter sérios inconvenientes é bom.