¿Existe una mala práctica para devolver unique_ptr para el puntero sin formato como semántica de propiedad?

Question

He escrito un método de fábrica estático que devuelve un nuevo objeto Foobar poblado de otro objeto de datos. Recientemente he estado obsesionado con la semántica de la propiedad y me pregunto si estoy transmitiendo el mensaje correcto al hacer que este método de fábrica devuelva un unique_ptr.

class Foobar { 
public: 
    static unique_ptr<Foobar> factory(DataObject data); 
} 

Mi intención es decirle al código del cliente que poseen el puntero. Sin un puntero inteligente, simplemente devolvería Foobar*. Sin embargo, me gustaría hacer que se elimine esta memoria para evitar posibles errores, por lo que unique_ptr parecía una solución adecuada. Si el cliente desea extender la vida útil del puntero, simplemente llama al .release() una vez que obtiene el unique_ptr.

Foobar* myFoo = Foobar::factory(data).release(); 

Mi pregunta viene en dos partes:

1. ¿Este enfoque transmitir la semántica de propiedad correctos?
2. ¿Es esto una "mala práctica" devolver unique_ptr en lugar de un puntero sin formato?

Answer 1

Devolver un std::unique_ptr de un método de fábrica está muy bien y debería ser una práctica recomendada. El mensaje que transmite es (IMO): Ahora usted es el único propietario de este objeto. Además, para su conveniencia, el objeto sabe cómo destruirse a sí mismo.

Creo que esto es mucho mejor que devolver un puntero sin formato (donde el cliente tiene que recordar cómo y si desechar este puntero).

Sin embargo, no entiendo su comentario sobre la liberación del puntero para extender su vida útil. En general, rara vez veo ningún motivo para llamar al release en un smartpointer, ya que creo que los punteros siempre deben estar gestionados por algún tipo de estructura RAII (casi la única situación en la que llamo release es poner el puntero en una estructura de gestión diferente, por ejemplo un unique_ptr con un eliminador diferente, después de que hice algo para garantizar una limpieza adicional).

Por lo tanto el cliente puede (y debe) simplemente almacenar el unique_ptr en alguna parte (tal como otro unique_ptr, que ha sido movida construido a partir de la devuelta), siempre y cuando que necesitan el objeto (o una shared_ptr, si necesitan varias copias del puntero).Así que el código del lado del cliente debe ser de la misma familia:

std::unique_ptr<FooBar> myFoo = Foobar::factory(data); 
//or: 
std::shared_ptr<FooBar> myFoo = Foobar::factory(data); 

Personalmente añadiría también un typedef para el tipo de puntero devuelto (en este caso std::unique_ptr<Foobar>) y la Deleter o usado (en este caso std :: default_deleter) a su objeto de fábrica. Eso hace que sea más fácil si luego decide cambiar la asignación de su puntero (y por lo tanto necesita un método diferente para la destrucción del puntero, que será visible como un segundo parámetro de plantilla de std::unique_ptr). Así que me gustaría hacer algo como esto:

class Foobar { 
public: 
    typedef std::default_deleter<Foobar>  deleter; 
    typedef std::unique_ptr<Foobar, deleter> unique_ptr; 

    static unique_ptr factory(DataObject data); 
} 

Foobar::unique_ptr myFoo = Foobar::factory(data); 
//or: 
std::shared_ptr<Foobar> myFoo = Foobar::factory(data); 

Answer 2

A std::unique_ptr posee el único objeto al que apunta. Dice "Poseo este objeto, y nadie más lo hace".

Eso es exactamente lo que estás tratando de expresar: estás diciendo "llamante de esta función: ahora eres el único propietario de este objeto; hazlo como quieras, su duración es tu responsabilidad".

Answer 3

Transmite exactamente la semántica correcta y es la forma en que creo que todas las fábricas en C++ deberían funcionar: std::unique_ptr<T> no impone ningún tipo de semántica de propiedad y es extremadamente barato.