2010-08-10 10 views
12

Recientemente comencé a apreciar std::auto_ptr y ahora leo que será deprecated. He empezado a utilizar para dos situaciones:¿Debo dejar de usar auto_ptr?

  • valor de retorno de una fábrica
  • Comunicar transferencia de la propiedad

Ejemplos:

// Exception safe and makes it clear that the caller has ownership. 
std::auto_ptr<Component> ComponentFactory::Create() { ... } 

// The receiving method/function takes ownership of the pointer. Zero ambiguity. 
void setValue(std::auto_ptr<Value> inValue); 

A pesar de la semántica de copia problemáticas encuentro auto_ptr útil. Y no parece haber una alternativa para los ejemplos anteriores.

¿Debería seguir usándolo y luego cambiar a std::unique_ptr? ¿O se debe evitar?

+2

Yo diría que sigas con 'auto_ptr' para cualquier proyecto en el que estés trabajando, y cambias siempre que comiences algo nuevo, para que no estés creando complejidad mezclándolos. (Supongo que el (los) compilador (es) que usa el soporte 'unique_ptr'.) –

+0

' std :: auto_ptr' se está desaprobando no porque no sea útil, sino porque 'std :: unique_ptr' hace todo lo que hace, simplemente mejor. Entonces, ya sea que cambie a 'std :: unique_ptr' o no, no hay razón para dejar de usar' std :: auto_ptr'. –

+0

Eric Lippert escribió sobre esto hace mucho tiempo. Es una lectura interesante: http://blogs.msdn.com/b/ericlippert/archive/2003/09/16/53016.aspx –

Respuesta

5

Es muy, muy útil, a pesar de sus defectos, que recomiendo seguir usándolo y cambiar a unique_ptr cuando esté disponible.

::std::unique_ptr requiere un compilador que admita referencias rvalue que son parte del borrador del estándar C++ 0x, y tardará un poco para que haya realmente un amplio soporte para él. Y hasta que las referencias de valores estén disponibles, ::std::auto_ptr es lo mejor que puede hacer.

Tener ambos ::std::auto_ptr y ::std::unique_ptr en su código puede confundir a algunas personas. Pero debería poder buscar y reemplazar por ::std::unique_ptr cuando decida cambiarlo. Puede obtener errores de compilador si lo hace, pero deberían ser fácilmente corregibles. La respuesta mejor valorada al this question about replacing ::std::auto_ptr with ::std::unique_tr tiene más detalles.

+0

Pero manténgase constante dentro de un proyecto. No hay nada peor que tener dos tipos que hacen lo mismo pero con diferentes nombres. –

+0

Técnicamente, 'unique_ptr' no es un reemplazo directo para' auto_ptr'. Entre otras cosas, cambia un posible bloqueo de tiempo de ejecución en un error de compilación definitivo. En general, esto es algo bueno, por lo que probablemente querrá hacer una búsqueda de reemplazo una vez que esté disponible, solucionando cualquier error de compilación que esto desencadene. Ver http://stackoverflow.com/questions/3451099 – Brian

+0

@Brian - Gracias por ese enlace. Incluiré su aclaración y ese enlace en mi respuesta de la mañana. :-) – Omnifarious

-1

Le sugiero que vaya a utilizar impulsar los punteros inteligentes.

+9

No resuelven el mismo problema. Boost no es la respuesta a todo, no importa cuán útil sea. – Omnifarious

+0

boost punteros inteligentes llevan cierta sobrecarga con ellos. shared_ptr realiza una asignación de memoria adicional, intrusive_ptr requiere un contador incrustado. no hay un buen sustituto para auto_ptr todavía. –

+0

Lo que Omni dijo. Ninguno de los indicadores inteligentes de boost admite la transferencia de propiedad, porque la biblioteca estándar ya proporciona esa funcionalidad tan bien como es posible en el estándar actual.Si 'std :: auto_ptr' funciona, usar cualquiera de los punteros compartidos de boost es casi seguro un error [' boost :: scoped_ptr' podría ser suficiente, pero esas situaciones son relativamente limitadas] –

1

obsoleto no significa que va a desaparecer, solo que habrá una mejor alternativa.

Sugiero seguir usándolo en el código actual, pero utilizando la nueva alternativa en el nuevo código (Nuevos programas o módulos, no pequeños cambios en el código actual). La consistencia es importante

+1

Significa que * podría * desaparecer en algún momento en el futuro sin embargo. – jalf

+0

Ha sido eliminado en C++ 17 http://en.cppreference.com/w/cpp/memory/auto_ptr –