Usando ponteiros inteligentes para os alunos

Estou tendo problemas para entender o uso de ponteiros inteligentes como membros da classe em C ++ 11. Eu li muito sobre ponteiros inteligentes e acho que entendo como unique_ptre shared_ptr/ weak_ptrtrabalho em geral. O que eu não entendo é o uso real. Parece que todo mundo recomenda usar unique_ptro caminho a percorrer quase o tempo todo. Mas como eu implementaria algo assim:

class Device {
};

class Settings {
    Device *device;
public:
    Settings(Device *device) {
        this->device = device;
    }

    Device *getDevice() {
        return device;
    }
};    

int main() {
    Device *device = new Device();
    Settings settings(device);
    // ...
    Device *myDevice = settings.getDevice();
    // do something with myDevice...
}

Digamos que eu gostaria de substituir os ponteiros por ponteiros inteligentes. A unique_ptrnão funcionaria por causa de getDevice(), certo? Então é nessa hora que eu uso shared_ptre weak_ptr? Não tem como usar unique_ptr? Parece-me que, na maioria dos casos, shared_ptrfaz mais sentido, a menos que eu esteja usando um ponteiro em um escopo muito pequeno?

class Device {
};

class Settings {
    std::shared_ptr<Device> device;
public:
    Settings(std::shared_ptr<Device> device) {
        this->device = device;
    }

    std::weak_ptr<Device> getDevice() {
        return device;
    }
};

int main() {
    std::shared_ptr<Device> device(new Device());
    Settings settings(device);
    // ...
    std::weak_ptr<Device> myDevice = settings.getDevice();
    // do something with myDevice...
}

Aquele é o caminho para ir? Muito obrigado!

A unique_ptrnão funcionaria por causa de getDevice(), certo?

Não, não necessariamente. O importante aqui é determinar a política de propriedade apropriada para o seu Deviceobjeto, ou seja, quem será o proprietário do objeto apontado pelo seu ponteiro (inteligente).

Será a instância do Settingsobjeto sozinha ? O Deviceobjeto terá que ser destruído automaticamente quando o Settingsobjeto for destruído ou deve sobreviver a ele?

No primeiro caso, std::unique_ptré o que você precisa, pois ele torna Settingso único (único) proprietário do objeto apontado e o único objeto responsável por sua destruição.

Sob essa suposição, getDevice()deve retornar um ponteiro de observação simples (observar ponteiros são ponteiros que não mantêm o objeto apontado vivo). O tipo mais simples de observação de ponteiro é um ponteiro bruto:

#include <memory>

class Device {
};

class Settings {
    std::unique_ptr<Device> device;
public:
    Settings(std::unique_ptr<Device> d) {
        device = std::move(d);
    }

    Device* getDevice() {
        return device.get();
    }
};

int main() {
    std::unique_ptr<Device> device(new Device());
    Settings settings(std::move(device));
    // ...
    Device *myDevice = settings.getDevice();
    // do something with myDevice...
}

[ NOTA 1: Você pode estar se perguntando por que estou usando ponteiros brutos aqui, quando todo mundo fica dizendo que os ponteiros brutos são ruins, inseguros e perigosos. Na verdade, esse é um aviso precioso, mas é importante colocá-lo no contexto correto: ponteiros brutos são ruins quando usados ​​para executar o gerenciamento manual de memória , ou seja, alocar e desalocar objetos através de newe delete. Quando usado puramente como um meio de obter semântica de referência e passar ponteiros não-proprietários, observando ponteiros, não há nada intrinsecamente perigoso em ponteiros brutos, exceto talvez pelo fato de que se deve tomar cuidado para não desreferenciar um ponteiro pendente. - NOTA FINAL 1 ]

[ NOTA 2: Como surgiu nos comentários, neste caso específico em que a propriedade é única e o objeto de propriedade sempre está presente (ou seja, o membro de dados interno devicenunca estará presente nullptr), a função getDevice()poderia (e talvez devesse) retornar uma referência em vez de um ponteiro. Embora isso seja verdade, eu decidi retornar um ponteiro bruto aqui, porque eu quis dizer que essa seria uma resposta curta que poderia ser generalizada para o caso em que devicepoderia estar nullptre mostrar que os ponteiros não processados ​​são bons, desde que não sejam usados ​​para gerenciamento manual de memória. - NOTA FINAL 2 ]

A situação é radicalmente diferente, é claro, se o seu Settingsobjeto não tiver a propriedade exclusiva do dispositivo. Este poderia ser o caso, por exemplo, se a destruição do Settingsobjeto não implicasse também a destruição do Deviceobjeto apontado .

Isso é algo que somente você, como designer do seu programa, pode dizer; pelo exemplo que você fornece, é difícil para mim dizer se esse é o caso ou não.

Para ajudá-lo a descobrir, você pode se perguntar se existem outros objetos além dos Settingsque têm o direito de manter o Deviceobjeto vivo enquanto mantiverem um ponteiro para ele, em vez de serem apenas observadores passivos. Se esse for realmente o caso, você precisará de uma política de propriedade compartilhada , que é o que std::shared_ptroferece:

#include <memory>

class Device {
};

class Settings {
    std::shared_ptr<Device> device;
public:
    Settings(std::shared_ptr<Device> const& d) {
        device = d;
    }

    std::shared_ptr<Device> getDevice() {
        return device;
    }
};

int main() {
    std::shared_ptr<Device> device = std::make_shared<Device>();
    Settings settings(device);
    // ...
    std::shared_ptr<Device> myDevice = settings.getDevice();
    // do something with myDevice...
}

Observe que weak_ptré um ponteiro de observação , não um ponteiro proprietário - em outras palavras, ele não mantém o objeto apontado vivo se todos os outros ponteiros proprietários do objeto apontado ficarem fora do escopo.

A vantagem de weak_ptrum ponteiro bruto comum é que você pode dizer com segurança se weak_ptrestá danificado ou não (por exemplo, se está apontando para um objeto válido ou se o objeto apontado originalmente foi destruído). Isso pode ser feito chamando a expired()função de membro no weak_ptrobjeto.

class Device {
};

class Settings {
    std::shared_ptr<Device> device;
public:
    Settings(const std::shared_ptr<Device>& device) : device(device) {

    }

    const std::shared_ptr<Device>& getDevice() {
        return device;
    }
};

int main()
{
    std::shared_ptr<Device> device(new Device());
    Settings settings(device);
    // ...
    std::shared_ptr<Device> myDevice(settings.getDevice());
    // do something with myDevice...
    return 0;
}

week_ptré usado apenas para loops de referência. O gráfico de dependência deve ser um gráfico direcionado acíclico. Nos ponteiros compartilhados, existem 2 contagens de referência: 1 para se shared_ptr1 para todos os ponteiros ( shared_ptre weak_ptr). Quando todos os shared_ptrs são removidos, o ponteiro é excluído. Quando o ponteiro é necessário weak_ptr, lockdeve ser usado para obter o ponteiro, se ele existir.