¿Qué tipo de puntero uso cuando?

Ok, entonces la última vez que escribí C ++ para ganarme la vida, std::auto_ptrera todo lo que tenía disponible la biblioteca estándar , y boost::shared_ptrestaba de moda. Realmente nunca examiné el aumento de otros tipos de punteros inteligentes proporcionados. Entiendo que C ++ 11 ahora proporciona algunos de los tipos que se le ocurrieron, pero no todos.

Entonces, ¿alguien tiene un algoritmo simple para determinar cuándo usar qué puntero inteligente? Preferiblemente incluye consejos sobre punteros tontos (como punteros crudos T*) y el resto de los punteros inteligentes de impulso. (Algo como esto sería genial).

Propiedad compartida:
El shared_ptry weak_ptrel estándar adoptado son más o menos lo mismo que sus contrapartes Boost . Úselos cuando necesite compartir un recurso y no sepa cuál será el último en estar vivo. Se usa weak_ptrpara observar el recurso compartido sin influir en su vida útil, no para romper ciclos. Los ciclos con shared_ptrnormalmente no deberían suceder: dos recursos no pueden ser dueños el uno del otro.

Tenga en cuenta que Boost también ofrece shared_array, que podría ser una alternativa adecuada a shared_ptr<std::vector<T> const>.

A continuación, Boost ofrece intrusive_ptr, que son una solución ligera si su recurso ya ofrece una gestión contada por referencia y desea adoptarla según el principio RAII. Este no fue adoptado por la norma.

Propiedad única:
Boost también tiene un scoped_ptr, que no es copiable y para el que no puede especificar un borrador. std::unique_ptrestá boost::scoped_ptren esteroides y debería ser su opción predeterminada cuando necesita un puntero inteligente . Le permite especificar un eliminador en sus argumentos de plantilla y es móvil , a diferencia boost::scoped_ptr. También es totalmente utilizable en contenedores STL siempre que no utilice operaciones que necesiten tipos copiables (obviamente).

Tenga en cuenta nuevamente que Boost tiene una versión de matriz: scoped_arrayque el estándar se unificó al requerir std::unique_ptr<T[]>una especialización parcial que utilizará delete[]el puntero en lugar de deleteutilizarlo (con la default_deleter). std::unique_ptr<T[]>también ofrece en operator[]lugar de operator*y operator->.

Tenga en cuenta que std::auto_ptrtodavía está en el estándar, pero está en desuso . §D.10 [depr.auto.ptr]

La plantilla de clase auto_ptrestá en desuso. [ Nota: La plantilla de clase unique_ptr(20.7.1) proporciona una mejor solución. —Nota final ]

Sin propiedad:
utilice punteros tontos (punteros sin procesar) o referencias para referencias que no sean propiedad de los recursos y cuando sepa que el recurso sobrevivirá al objeto / alcance de referencia. Prefiera referencias y use punteros sin procesar cuando necesite nulabilidad o reiniciabilidad.

Si desea una referencia no propietaria de un recurso, pero no sabe si el recurso sobrevivirá al objeto que hace referencia a él, empaque el recurso en ay shared_ptruse un weak_ptr- puede probar si el padre shared_ptrestá vivo lock, lo que devuelve un shared_ptrque no es nulo si el recurso todavía existe. Si desea probar si el recurso está muerto, úselo expired. Los dos pueden sonar similares, pero son muy diferentes frente a la ejecución concurrente, ya que expiredsolo garantiza su valor de retorno para esa declaración única. Una prueba aparentemente inocente como

if(!wptr.expired())
  something_assuming_the_resource_is_still_alive();

Es una posible condición de carrera.

Decidir qué puntero inteligente usar es una cuestión de propiedad . Cuando se trata de la gestión de recursos, el objeto A posee el objeto B si está en control de la vida útil del objeto B. Por ejemplo, las variables miembro son propiedad de sus respectivos objetos porque la vida útil de las variables miembro está vinculada a la vida útil del objeto. Elige punteros inteligentes en función de cómo se posee el objeto.

Tenga en cuenta que la propiedad en un sistema de software es independiente de la propiedad, ya que podríamos pensar fuera de él. Por ejemplo, una persona puede "ser propietaria" de su hogar, pero eso no significa necesariamente que un Personobjeto tenga control sobre la vida útil de un Houseobjeto. Combinar estos conceptos del mundo real con los conceptos de software es una forma segura de programarse en un hoyo.

Si tiene la propiedad exclusiva del objeto, úselo std::unique_ptr<T>.

Si ha compartido la propiedad del objeto ...
- Si no hay ciclos de propiedad, use std::shared_ptr<T>.
- Si hay ciclos, defina una "dirección" y úsela std::shared_ptr<T>en una dirección y std::weak_ptr<T>en la otra.

Si el objeto lo posee, pero existe la posibilidad de no tener un propietario, utilice punteros normales T*(por ejemplo, punteros principales).

Si el objeto es tuyo (o de lo contrario tiene existencia garantizada), usa referencias T&.

Advertencia: Tenga en cuenta los costos de los punteros inteligentes. En entornos con memoria o rendimiento limitado, podría ser beneficioso usar punteros normales con un esquema más manual para administrar la memoria.

Los costos:

• Si tiene un eliminador personalizado (p. Ej., Utiliza grupos de asignación), esto generará una sobrecarga por puntero que puede evitarse fácilmente mediante la eliminación manual.
• std::shared_ptrtiene la sobrecarga de un incremento de recuento de referencia en la copia, más una disminución en la destrucción seguida de una verificación de recuento de 0 con la eliminación del objeto retenido. Dependiendo de la implementación, esto puede inflar su código y causar problemas de rendimiento.
• Tiempo de compilación. Al igual que con todas las plantillas, los punteros inteligentes contribuyen negativamente a los tiempos de compilación.

Ejemplos:

struct BinaryTree
{
    Tree* m_parent;
    std::unique_ptr<BinaryTree> m_children[2]; // or use std::array...
};

Un árbol binario no posee su padre, pero la existencia de un árbol implica la existencia de su padre (o nullptrde raíz), por lo que utiliza un puntero normal. Un árbol binario (con semántica de valor) tiene la propiedad exclusiva de sus hijos, por lo que son std::unique_ptr.

struct ListNode
{
    std::shared_ptr<ListNode> m_next;
    std::weak_ptr<ListNode> m_prev;
};

Aquí, el nodo de lista posee sus listas siguiente y anterior, por lo que definimos una dirección y la usamos shared_ptrpara siguiente y weak_ptranterior para romper el ciclo.

Utilizar unique_ptr<T> todo el tiempo, excepto cuando necesite un recuento de referencias, en cuyo caso use shared_ptr<T>(y en casos muy raros, weak_ptr<T>para evitar ciclos de referencia). En casi todos los casos, la propiedad única transferible está bien.

Punteros sin procesar: buenos solo si necesita retornos covariantes, puntería no propietaria que puede suceder. De lo contrario, no son terriblemente útiles.

Punteros de matriz: unique_ptrtiene una especialización para la T[]que se solicita automáticamente delete[]el resultado, por lo que puede hacerlo con seguridad, unique_ptr<int[]> p(new int[42]);por ejemplo. shared_ptraún necesitaría un eliminador personalizado, pero no necesitaría un puntero de matriz compartido o único especializado. Por supuesto, tales cosas generalmente se reemplazan mejor de std::vectortodos modos. Desafortunadamente shared_ptr, no proporciona una función de acceso a matriz, por lo que aún tendría que llamar manualmente get(), pero unique_ptr<T[]>proporciona en operator[]lugar de operator*y operator->. En cualquier caso, tienes que verificarte los límites. Esto hace que sea un shared_ptrpoco menos fácil de usar, aunque podría decirse que es una ventaja genérica y que ninguna dependencia de Boost hace unique_ptryshared_ptr los ganadores nuevamente.

Indicadores de alcance: se vuelven irrelevantes unique_ptr, al igual queauto_ptr .

Realmente no hay nada más. En C ++ 03 sin semántica de movimiento, esta situación era muy complicada, pero en C ++ 11 el consejo es muy simple.

Todavía hay usos para otros punteros inteligentes, como intrusive_ptro interprocess_ptr. Sin embargo, son muy específicos y completamente innecesarios en el caso general.

Casos de cuándo usar unique_ptr:

• Métodos de fábrica
• Miembros que son punteros (incluido pimpl)
• Almacenamiento de punteros en contenedores stl (para evitar movimientos)
• Uso de grandes objetos dinámicos locales.

Casos de cuándo usar shared_ptr:

• Compartir objetos a través de hilos
• Compartir objetos en general

Casos de cuándo usar weak_ptr:

• Mapa grande que actúa como referencia general (por ejemplo, un mapa de todos los sockets abiertos)

Siéntase libre de editar y agregar más