¿Por qué se desaprueba auto_ptr?

Escuché que auto_ptrestá siendo obsoleto en C ++ 11. ¿Cuál es la razón para esto?

También me gustaría saber la diferencia entre auto_ptry shared_ptr.

El reemplazo directo de auto_ptr(o lo más parecido a uno de todos modos) es unique_ptr. En lo que respecta al "problema", es bastante simple: auto_ptrtransfiere la propiedad cuando se asigna. unique_ptrtambién transfiere la propiedad, pero gracias a la codificación de la semántica de movimientos y la magia de las referencias rvalue, puede hacerlo de forma considerablemente más natural. También "encaja" con el resto de la biblioteca estándar considerablemente mejor (aunque, para ser justos, algo de eso se debe a que el resto de la biblioteca cambió para adaptarse a la semántica de movimiento en lugar de requerir siempre copia).

El cambio de nombre también es (en mi opinión) bienvenido: en auto_ptrrealidad no le dice mucho sobre lo que intenta automatizar, mientras que unique_ptres una descripción bastante razonable (aunque concisa) de lo que se proporciona.

Encontré excelentes respuestas existentes, pero desde el punto de vista de los punteros. En mi opinión, una respuesta ideal debe tener la respuesta de perspectiva del usuario / programador.

Primero lo primero (como lo señaló Jerry Coffin en su respuesta)

• auto_ptr podría ser reemplazado por shared_ptr o unique_ptr dependiendo de la situación

shared_ptr: Si le preocupa la liberación de recursos / memoria Y si tiene más de una función que podría estar usando el objeto AT-DIFFERENT veces, vaya con shared_ptr.

Por DIFFERENT-Times, piense en una situación en la que el objeto-ptr se almacena en múltiples estructuras de datos y luego se accede a él. Varios hilos, por supuesto, es otro ejemplo.

unique_ptr: Si lo único que le preocupa es liberar memoria y el acceso al objeto es SECUENCIAL, elija unique_ptr.

Por SECUENCIAL, quiero decir, en cualquier punto se accederá al objeto desde un contexto. Por ejemplo, un objeto que fue creado y utilizado inmediatamente después de la creación por el creador. Después de la creación, el objeto se almacena en la PRIMERA estructura de datos. Luego, el objeto se destruye después de la UNA estructura de datos o se mueve a la SEGUNDA estructura de datos.

Desde esta línea, me referiré a _ptr compartido / único como punteros inteligentes. (auto_ptr también es un puntero inteligente, PERO debido a fallas en su diseño, por lo que están en desuso, y que creo que señalaré en las siguientes líneas, no deben agruparse con el puntero inteligente).

La única razón más importante de por qué auto_ptr se desaprobó en favor de smart-pointer es la semántica de asignación. Si no fuera por esa razón, habrían agregado todas las novedades de la semántica de movimiento a auto_ptr en lugar de desaprobarlo. Dado que la semántica de asignación era la característica más desagradable, querían que esa característica desapareciera, pero como hay código escrito que usa esa semántica (que el comité de estándares no puede cambiar), tuvieron que dejar de lado auto_ptr, en lugar de modificarlo.

Desde el enlace: http://www.cplusplus.com/reference/memory/unique_ptr/operator=/

Tipo de asignaciones admitidas por unqiue_ptr

• mover asignación (1)
• asignar puntero nulo (2)
• asignación tipográfica (3)
• copiar asignación (eliminada!) (4)

De: http://www.cplusplus.com/reference/memory/auto_ptr/operator=/

Tipo de asignaciones admitidas por auto_ptr

• copiar asignación (4) culpable

Ahora, llegando a la razón por la que la asignación de copia en sí misma no le gustó tanto, tengo esta teoría:

1. No todos los programadores leen libros o estándares
2. auto_ptr en la cara, le promete la propiedad del objeto
3. la pequeña- * (juego de palabras), cláusula del auto_ptr, que no es leída por todos los programadores, permite la asignación de un auto_ptr a otro y transfiere la propiedad.
4. Las investigaciones han demostrado que este comportamiento está destinado al 3,1415926535% de todo el uso y no previsto en otros casos.

El comportamiento no deseado es realmente desagradable y, por lo tanto, el desagrado por auto_ptr.

(Para el 3.1415926536% de los programadores que intencionalmente quieren transferir la propiedad, C ++ 11 les dio std :: move (), lo que dejó en claro su intención para todos los pasantes que leerán y mantendrán el código).

shared_ptrse puede almacenar dentro de contenedores. auto_ptrhipocresía.

Por cierto, unique_ptres realmente el auto_ptrreemplazo directo , combina las mejores características de ambos std::auto_ptry boost::scoped_ptr.

Otra versión más para explicar la diferencia ...

Funcionalmente, C ++ 11 std::unique_ptres el "fijo" std::auto_ptr: ambos son adecuados cuando, en cualquier momento durante la ejecución, debería haber un único propietario de puntero inteligente para un objeto apuntado.

La diferencia crucial está en la construcción de copias o la asignación de otro puntero inteligente que no expira, que se muestra en las =>líneas siguientes:

   std::auto_ptr<T> ap(...);
   std::auto_ptr<T> ap2(get_ap_to_T());   // take expiring ownership
=> std::auto_ptr<T> ap3(ap);  // take un-expiring ownership ala ap3(ap.release());
   ap->xyz;  // oops... can still try to use ap, expecting it to be non-NULL

   std::unique_ptr<T> up(...);
   std::unique_ptr<T> up2(get_up_to_T());   // take expiring ownership
=> std::unique_ptr<T> up3(up);  // COMPILE ERROR: can't take un-expiring ownership
=> std::unique_ptr<T> up4(std::move(up));  // EXPLICIT code allowed
=> std::unique_ptr<T> up4(up.release());   // EXPLICIT code allowed

Arriba, ap3silenciosamente "roba" la propiedad de *ap, dejándolo apconfigurado en a nullptr, y el problema es que puede suceder con demasiada facilidad, sin que el programador haya pensado en su seguridad.

Por ejemplo, si un class/ structtiene un std::auto_ptrmiembro, al hacer una copia de una instancia aparecerá releaseel puntero de la instancia que se está copiando: esa es una semántica extraña y peligrosamente confusa, ya que normalmente copiar algo no lo modifica. Es fácil para el autor de la clase / estructura pasar por alto la liberación del puntero cuando razona sobre invariantes y estados y, en consecuencia, intenta accidentalmente desreferenciar el puntero inteligente mientras es nulo, o simplemente no tiene el acceso / propiedad esperado de los datos apuntados.

auto_ptr no se puede usar en contenedores STL porque tiene un constructor de copia que no cumple con los requisitos del contenedor CopyConstructible . unique_ptr no implementa un constructor de copia, por lo que los contenedores usan métodos alternativos. unique_ptr se puede usar en contenedores y es más rápido para los algoritmos estándar que shared_ptr.

#include <iostream>
#include <type_traits>
#include <vector>
#include <memory>

using namespace std;

int main() {
  cout << boolalpha;
  cout << "is_copy_constructible:" << endl;
  cout << "auto_ptr: " << is_copy_constructible< auto_ptr<int> >::value << endl;
  cout << "unique_ptr: " << is_copy_constructible< unique_ptr<int> >::value << endl;
  cout << "shared_ptr: " << is_copy_constructible< shared_ptr<int> >::value << endl;

  vector<int> i_v;
  i_v.push_back(1);
  cout << "i_v=" << i_v[0] << endl;
  vector<int> i_v2=i_v;
  cout << "i_v2=" << i_v2[0] << endl;

  vector< unique_ptr<int> > u_v;
  u_v.push_back(unique_ptr<int>(new int(2)));
  cout << "u_v=" << *u_v[0] << endl;
  //vector< unique_ptr<int> > u_v2=u_v;  //will not compile, need is_copy_constructible == true
  vector< unique_ptr<int> > u_v2 =std::move(u_v);  // but can be moved
  cout << "u_v2=" << *u_v2[0] << " length u_v: " <<u_v.size() << endl;

  vector< shared_ptr<int> > s_v;
  shared_ptr<int> s(new int(3));
  s_v.push_back(s);
  cout << "s_v=" << *s_v[0] << endl;
  vector< shared_ptr<int> > s_v2=s_v;
  cout << "s_v2=" << *s_v2[0] << endl;

  vector< auto_ptr<int> > a_v;  //USAGE ERROR

  return 0;
}

>cxx test1.cpp -o test1
test1.cpp: In function âint main()â:
test1.cpp:33:11: warning: âauto_ptrâ is deprecated (declared at /apps/hermes/sw/gcc/gcc-4.8.5/include/c++/4.8.5/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
   vector< auto_ptr<int> > a_v;  //USAGE ERROR
           ^
>./test1
is_copy_constructible:
auto_ptr: false
unique_ptr: false
shared_ptr: true
i_v=1
i_v2=1
u_v=2
s_v=3
s_v2=3