shared_ptr vs scoped_ptr

Question

scoped_ptr não é capaz de copiar e está sendo excluído do escopo. Então é meio restrito shared_ptr. Então parece além dos casos quando você realmente precisa restringir a operação de cópia shared_ptr é melhor usar. Porque às vezes você não sabe que precisa criar uma cópia do seu objeto ou não. Portanto, a questão é: além dos casos mencionados acima, poderíamos considerar que shared_ptr é melhor (ou recomendado) para usar em vez de scoped_ptr. Faz scoped_ptr trabalhar muito mais rápido de shared_ptr, ou tem alguma vantagem?

Obrigado!

Answer 1

shared_ptr é mais pesado do que scoped_ptr. Ele precisa alocar e liberar um objeto de contagem de referência, bem como o objeto gerenciado e lidar com a contagem de referência segura para roscas - em uma plataforma em que trabalhei, essa foi uma sobrecarga significativa.

Meu conselho (em geral) é usar o objeto mais simples que atenda às suas necessidades. Se você precisar de compartilhamento de referência, use shared_ptr; Se você só precisar de exclusão automática depois de terminar com uma única referência, use scoped_ptr.

Answer 2

atuação - shared_ptr tem mais funcionalidade, mas também requer uma alocação adicional (também é maior, mas isso raramente importa).

Editar] A segunda alocação pode ser evitada usando make_shared, mas então weak_ptr manterá toda a alocação inteira mesmo depois que o objeto for destruído, o que pode ser um problema para objetos grandes.

Expreseação de intenção usando scoped_ptr Você afirma mais explicitamente o que deseja fazer. (Caso você se pergunte - isso é uma coisa boa :)). Se você fizer isso corretamente, Shared_Ptr também indicará "Este objeto se destina a viver além desse escopo"

Answer 3

O objetivo pretendido é diferente, portanto, em muitos casos "Shared_Ptr vs Scoped_Ptr" não é uma pergunta. Claro, você pode usar um shared_ptr quando tudo o que você precisa é de um Scoped_ptr. Mas qual é o sentido? Shared_Ptr provavelmente tem uma sobrecarga um pouco maior com toda a contagem de referência envolvida.

Answer 4

scoped_ptr funciona muito mais rápido de shared_ptr. Está certo. shared_ptr Sempre aloque a memória usando seu alocador ou alocador padrão.

Answer 5

Scoped_Ptr tem pouco em comum com shared_ptr, fracas_ptr ou exclusivo_ptr porque está apenas fazendo um caso muito especial de "contagem de referência". Não é algo que você precisará com muita frequência em código bem projetado, mas é uma boa ferramenta disponível.

Basicamente, um Scoped_PTR não é uma coisa de referência. Em vez disso, é um objeto que você cria na pilha (dentro do escopo local) para que você possa fazer algo assim:

  //Some enclosing scope- anything set off by "{}" or even a function:
   {
       scoped_ptr<MyObject> ptr = new MyObject( parameters...);
   } // When we hit this closing brace, "ptr" will delete the "MyObject" inside.

Você tende a ver esse padrão mais com mutexes e outros primativos de sincronização- posso declarar um "Autolock" que bloqueará o mutex passado nele e, em seguida, desbloqueá-lo quando ele excluir o escopo "{}" em uma seção crítica.

Observe também que um 'scoped_ptr' só faz sentido quando você não pode simplesmente fazer uma alocação de pilha simples como "myObject obj (params ..)" por algum motivo. Afinal, o que está fazendo é deixar você usar um objeto alocado por heap como se estivesse na pilha. Isso tende a ser um caso de uso muito mais raro do que a contagem de referência de Shared_Ptr e seus primos.