Por que eu std :: move um std :: shared_ptr?

Estive pesquisando o código-fonte do Clang e encontrei este trecho:

void CompilerInstance::setInvocation(
    std::shared_ptr<CompilerInvocation> Value) {
  Invocation = std::move(Value);
}

Por que eu iria querer std::moveum std::shared_ptr?

Existe algum ponto em transferir a propriedade de um recurso compartilhado?

Por que eu não faria isso?

void CompilerInstance::setInvocation(
    std::shared_ptr<CompilerInvocation> Value) {
  Invocation = Value;
}

Eu acho que a única coisa que as outras respostas não enfatizaram o suficiente é o ponto da velocidade .

std::shared_ptra contagem de referência é atômica . aumentar ou diminuir a contagem de referência requer incremento ou decremento atômico . Isso é cem vezes mais lento que o incremento / decremento não atômico , sem mencionar que, se incrementarmos e diminuirmos o mesmo contador, acabaremos com o número exato, desperdiçando uma tonelada de tempo e recursos no processo.

Movendo o em shared_ptrvez de copiá-lo, "roubamos" a contagem de referência atômica e anulamos o outro shared_ptr. "roubar" a contagem de referência não é atômica e é cem vezes mais rápido que copiar o shared_ptr(e causar incremento ou decréscimo de referência atômica ).

Observe que essa técnica é usada exclusivamente para otimização. copiá-lo (como você sugeriu) é tão bom quanto em termos de funcionalidade.

Ao usar, movevocê evita aumentar e diminuir imediatamente o número de compartilhamentos. Isso pode economizar algumas operações atômicas caras na contagem de uso.

As operações de movimentação (como o construtor de movimentação) std::shared_ptrsão baratas , pois basicamente são "indicadores de roubo" (da origem para o destino; para ser mais preciso, todo o bloco de controle de estado é "roubado" da origem para o destino, incluindo as informações da contagem de referência) .

Em vez disso, as operações de cópia ao std::shared_ptrinvocar o aumento da contagem de referência atômica (ou seja, não apenas ++RefCountem um RefCountmembro de dados inteiro , mas, por exemplo, chamando o InterlockedIncrementWindows), que é mais caro do que apenas roubar ponteiros / estado.

Portanto, analisando a dinâmica da contagem de ref deste caso em detalhes:

// shared_ptr<CompilerInvocation> sp;
compilerInstance.setInvocation(sp);

Se você passar sppor valor e tirar uma cópia dentro do CompilerInstance::setInvocationmétodo, você terá:

1. Ao inserir o método, o shared_ptrparâmetro é construído com cópia: ref count incremento atômico .
2. Dentro do corpo do método, você copia o shared_ptrparâmetro no membro de dados: ref count incremento atômico .
3. Ao sair do método, o shared_ptrparâmetro é destruído: ref count decrement atomic .

Você tem dois incrementos atômicos e um decréscimo atômico, para um total de três operações atômicas .

Em vez disso, se você passar o shared_ptrparâmetro por valor e depois std::movedentro do método (conforme feito corretamente no código de Clang), você terá:

1. Ao inserir o método, o shared_ptrparâmetro é construído com cópia: ref count incremento atômico .
2. Dentro do corpo do método, você std::moveo shared_ptrparâmetro no membro de dados: ref count não muda! Você está apenas roubando ponteiros / estado: não há operações caras de contagem atômica de ref.
3. Ao sair do método, o shared_ptrparâmetro é destruído; mas desde que você avançou na etapa 2, não há nada para destruir, pois o shared_ptrparâmetro não está mais apontando para nada. Novamente, nenhum decréscimo atômico acontece neste caso.

Conclusão: neste caso, você obtém apenas um incremento atômico de contagem de ref, ou seja, apenas uma operação atômica .
Como você pode ver, isso é muito melhor do que dois incrementos atômicos mais um decréscimo atômico (para um total de três operações atômicas) para o caso da cópia.

Copiar a shared_ptrenvolve copiar seu ponteiro de objeto de estado interno e alterar a contagem de referência. Movê-lo envolve apenas a troca de ponteiros para o contador de referência interno e o objeto de propriedade, por isso é mais rápido.

Há duas razões para usar std :: move nessa situação. A maioria das respostas abordou a questão da velocidade, mas ignorou a questão importante de mostrar a intenção do código com mais clareza.

Para um std :: shared_ptr, std :: move indica inequivocamente uma transferência de propriedade do apontador, enquanto uma operação de cópia simples adiciona um proprietário adicional. Obviamente, se o proprietário original posteriormente abandonar sua propriedade (como permitir que seu std :: shared_ptr seja destruído), uma transferência de propriedade será realizada.

Quando você transfere a propriedade com std :: move, é óbvio o que está acontecendo. Se você usar uma cópia normal, não é óbvio que a operação pretendida é uma transferência até que você verifique se o proprietário original renuncia imediatamente à propriedade. Como bônus, é possível uma implementação mais eficiente, uma vez que uma transferência atômica de propriedade pode evitar o estado temporário em que o número de proprietários aumentou em um (e o assistente muda nas contagens de referência).

Pelo menos com o libstdc ++, você deve obter o mesmo desempenho com movimentação e atribuição, porque operator=chama std::moveo ponteiro recebido. Consulte: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr.h#L384