¿Hay algún uso para unique_ptr con array?

std::unique_ptr tiene soporte para matrices, por ejemplo:

std::unique_ptr<int[]> p(new int[10]);

pero es necesario? probablemente sea más conveniente usar std::vectoro std::array.

¿Encuentra algún uso para esa construcción?

Algunas personas no tienen el lujo de usar std::vector, incluso con asignadores. Algunas personas necesitan una matriz de tamaño dinámico, por lo que std::arrayestá fuera. Y algunas personas obtienen sus matrices de otro código que se sabe que devuelve una matriz; y ese código no se reescribirá para devolver un vectoro algo.

Al permitir unique_ptr<T[]>, usted atiende esas necesidades.

En resumen, usas unique_ptr<T[]>cuando necesita . Cuando las alternativas simplemente no van a funcionar para usted. Es una herramienta de último recurso.

Hay compensaciones, y usted elige la solución que coincide con lo que desea. La parte superior de mi cabeza:

Tamaño inicial

• vectory unique_ptr<T[]>permitir que se especifique el tamaño en tiempo de ejecución
• array solo permite especificar el tamaño en tiempo de compilación

Redimensionando

• arrayy unique_ptr<T[]>no permitir cambiar el tamaño
• vector hace

Almacenamiento

• vectory unique_ptr<T[]>almacenar los datos fuera del objeto (generalmente en el montón)
• array almacena los datos directamente en el objeto

Proceso de copiar

• arrayy vectorpermitir copiar
• unique_ptr<T[]> no permite copiar

Intercambiar / mover

• vectory unique_ptr<T[]>tener O (1) tiempo swapy operaciones de movimiento
• arraytiene O (n) tiempo swapy operaciones de movimiento, donde n es el número de elementos en la matriz

Invalidación de puntero / referencia / iterador

• array garantiza que los punteros, las referencias y los iteradores nunca se invaliden mientras el objeto esté activo, incluso en swap()
• unique_ptr<T[]>no tiene iteradores; los punteros y las referencias solo se invalidan swap()mientras el objeto está activo. (Después del intercambio, los punteros apuntan a la matriz con la que intercambió, por lo que siguen siendo "válidos" en ese sentido).
• vector puede invalidar punteros, referencias e iteradores en cualquier reasignación (y proporciona algunas garantías de que la reasignación solo puede ocurrir en ciertas operaciones).

Compatibilidad con conceptos y algoritmos.

• arrayy vectorson ambos contenedores
• unique_ptr<T[]> no es un contenedor

Debo admitir que parece una oportunidad para refactorizar el diseño basado en políticas.

Una razón por la que puede usar a unique_ptres si no desea pagar el costo de tiempo de ejecución de la inicialización del valor de la matriz.

std::vector<char> vec(1000000); // allocates AND value-initializes 1000000 chars

std::unique_ptr<char[]> p(new char[1000000]); // allocates storage for 1000000 chars

El std::vectorconstructor y el std::vector::resize()valor inicializarán T, pero newno lo harán siT es un POD.

Ver objetos inicializados en C ++ 11 y std :: vector constructor

Tenga en cuenta que vector::reserveno es una alternativa aquí: ¿Es seguro acceder al puntero sin formato después de std :: vector :: reserve?

Es la misma razón un programador C podría elegir mallocmás calloc.

Se std::vectorpuede copiar una, mientras que unique_ptr<int[]>permite expresar la propiedad única de la matriz. std::array, por otro lado, requiere que el tamaño se determine en tiempo de compilación, lo que puede ser imposible en algunas situaciones.

Scott Meyers tiene esto que decir en Effective Modern C ++

La existencia de std::unique_ptrmatrices for debería ser de solo interés intelectual para usted, ya que std::array, virtualmente std::vector, std::stringson mejores opciones de estructura de datos que las matrices sin procesar. La única situación que puedo concebir cuando una std::unique_ptr<T[]>tendría sentido sería cuando está utilizando una API tipo C que devuelve un puntero sin formato a una matriz de montón de la que asume la propiedad.

Sin embargo, creo que la respuesta de Charles Salvia es relevante: esa std::unique_ptr<T[]>es la única forma de inicializar una matriz vacía cuyo tamaño no se conoce en el momento de la compilación. ¿Qué diría Scott Meyers sobre esta motivación para usar std::unique_ptr<T[]>?

Contrariamente a std::vectory std::array, std::unique_ptrpuede poseer un puntero NULL.
Esto es útil cuando se trabaja con API de C que esperan una matriz o NULL:

void legacy_func(const int *array_or_null);

void some_func() {    
    std::unique_ptr<int[]> ptr;
    if (some_condition) {
        ptr.reset(new int[10]);
    }

    legacy_func(ptr.get());
}

Solía unique_ptr<char[]>implementar una agrupación de memoria preasignada utilizada en un motor de juego. La idea es proporcionar agrupaciones de memoria preasignadas utilizadas en lugar de asignaciones dinámicas para devolver resultados de solicitudes de colisión y otras cosas como la física de partículas sin tener que asignar / liberar memoria en cada cuadro. Es bastante conveniente para este tipo de escenarios en los que necesita grupos de memoria para asignar objetos con un tiempo de vida limitado (generalmente uno, 2 o 3 cuadros) que no requieren lógica de destrucción (solo desasignación de memoria).

Se puede encontrar un patrón común en algunas llamadas de la API de Windows Win32 , en el que el uso de std::unique_ptr<T[]>puede ser útil, por ejemplo, cuando no sabe exactamente qué tan grande debe ser un búfer de salida cuando se llama a alguna API de Win32 (que escribirá algunos datos dentro ese búfer):

// Buffer dynamically allocated by the caller, and filled by some Win32 API function.
// (Allocation will be made inside the 'while' loop below.)
std::unique_ptr<BYTE[]> buffer;

// Buffer length, in bytes.
// Initialize with some initial length that you expect to succeed at the first API call.
UINT32 bufferLength = /* ... */;

LONG returnCode = ERROR_INSUFFICIENT_BUFFER;
while (returnCode == ERROR_INSUFFICIENT_BUFFER)
{
    // Allocate buffer of specified length
    buffer.reset( BYTE[bufferLength] );
    //        
    // Or, in C++14, could use make_unique() instead, e.g.
    //
    // buffer = std::make_unique<BYTE[]>(bufferLength);
    //

    //
    // Call some Win32 API.
    //
    // If the size of the buffer (stored in 'bufferLength') is not big enough,
    // the API will return ERROR_INSUFFICIENT_BUFFER, and the required size
    // in the [in, out] parameter 'bufferLength'.
    // In that case, there will be another try in the next loop iteration
    // (with the allocation of a bigger buffer).
    //
    // Else, we'll exit the while loop body, and there will be either a failure
    // different from ERROR_INSUFFICIENT_BUFFER, or the call will be successful
    // and the required information will be available in the buffer.
    //
    returnCode = ::SomeApiCall(inParam1, inParam2, inParam3, 
                               &bufferLength, // size of output buffer
                               buffer.get(),  // output buffer pointer
                               &outParam1, &outParam2);
}

if (Failed(returnCode))
{
    // Handle failure, or throw exception, etc.
    ...
}

// All right!
// Do some processing with the returned information...
...

Me enfrenté a un caso en el que tenía que usar std::unique_ptr<bool[]>, que estaba en la biblioteca HDF5 (una biblioteca para el almacenamiento eficiente de datos binarios, que se usaba mucho en ciencia). Algunos compiladores (Visual Studio 2015 en mi caso) proporcionan compresiónstd::vector<bool> (mediante el uso de 8 bools en cada byte), lo cual es una catástrofe para algo como HDF5, que no se preocupa por esa compresión. Constd::vector<bool> , HDF5 finalmente estaba leyendo basura debido a esa compresión.

¿Adivina quién estuvo allí para el rescate, en un caso en el std::vectorque no funcionó, y necesitaba asignar una matriz dinámica limpiamente? :-)

En pocas palabras: es, con mucho, el más eficiente en memoria.

A std::stringviene con un puntero, una longitud y un búfer de "optimización de cadenas cortas". Pero mi situación es que necesito almacenar una cadena que casi siempre está vacía, en una estructura que tengo cientos de miles. En C, solo usaría char *, y sería nulo la mayor parte del tiempo. Lo que también funciona para C ++, excepto que a char *no tiene destructor y no sabe eliminarse. Por el contrario, a std::unique_ptr<char[]>se eliminará a sí mismo cuando salga del alcance. Un vacío std::stringocupa 32 bytes, pero un vacíostd::unique_ptr<char[]> ocupa 8 bytes, es decir, exactamente el tamaño de su puntero.

El mayor inconveniente es que cada vez que quiero saber la longitud de la cadena, tengo que recurrir strlena ella.

Para responder a las personas que piensan que "tiene que" usarlas en vectorlugar de unique_ptrtener un caso en la programación CUDA en la GPU, cuando asigna memoria en el Dispositivo, debe elegir una matriz de puntero (con cudaMalloc). Luego, al recuperar estos datos en el Host, debe volver a buscar un puntero y unique_ptrestá bien manejarlo fácilmente. El costo adicional de la conversión double*a vector<double>es innecesario y conduce a una pérdida de rendimiento.

Una razón adicional para permitir y usar std::unique_ptr<T[]> , que no se ha mencionado en las respuestas hasta ahora: le permite declarar hacia adelante el tipo de elemento de matriz.

Esto es útil cuando quieres minimizar el encadenado #include declaraciones en los encabezados (para optimizar el rendimiento de compilación)

Por ejemplo -

myclass.h:

class ALargeAndComplicatedClassWithLotsOfDependencies;

class MyClass {
   ...
private:
   std::unique_ptr<ALargeAndComplicatedClassWithLotsOfDependencies[]> m_InternalArray;
};

myclass.cpp:

#include "myclass.h"
#include "ALargeAndComplicatedClassWithLotsOfDependencies.h"

// MyClass implementation goes here

Con la estructura de código anterior, cualquier persona puede #include "myclass.h"y el uso MyClass, sin tener que incluir las dependencias de implementación internos requeridos por MyClass::m_InternalArray.

Si m_InternalArrayse declarara como a std::array<ALargeAndComplicatedClassWithLotsOfDependencies>, o a std::vector<...>, respectivamente, el resultado sería un intento de uso de un tipo incompleto, que es un error en tiempo de compilación.

No puedo estar en desacuerdo con el espíritu de la respuesta aceptada con suficiente fuerza. ¿"Una herramienta de último recurso"? ¡Lejos de ahi!

A mi modo de ver, una de las características más fuertes de C ++ en comparación con C y con otros lenguajes similares es la capacidad de expresar restricciones para que puedan verificarse en el momento de la compilación y se pueda evitar el uso accidental. Entonces, al diseñar una estructura, pregúntese qué operaciones debería permitir. Todos los demás usos deberían estar prohibidos, y es mejor si tales restricciones pueden implementarse estáticamente (en el momento de la compilación) para que el mal uso provoque un error de compilación.

Entonces, cuando se necesita una matriz, las respuestas a las siguientes preguntas especifican su comportamiento: 1. ¿Es su tamaño a) dinámico en tiempo de ejecución, o b) estático, pero solo conocido en tiempo de ejecución, o c) estático y conocido en tiempo de compilación? 2. ¿Se puede asignar la matriz en la pila o no?

Y en base a las respuestas, esto es lo que veo como la mejor estructura de datos para dicha matriz:

       Dynamic     |   Runtime static   |         Static
Stack std::vector      unique_ptr<T[]>          std::array
Heap  std::vector      unique_ptr<T[]>     unique_ptr<std::array>

Sí, creo unique_ptr<std::array> que también debería considerarse, y tampoco es una herramienta de último recurso. Solo piense qué se adapta mejor a su algoritmo.

Todos estos son compatibles con API C simples a través del puntero sin formato a la matriz de datos ( vector.data()/ array.data()/ uniquePtr.get()).

PD Además de las consideraciones anteriores, también hay una de propiedad: std::arrayy std::vectortiene una semántica de valor (tiene soporte nativo para copiar y pasar por valor), mientras unique_ptr<T[]>que solo se puede mover (impone la propiedad única). Cualquiera puede ser útil en diferentes escenarios. Por el contrario, las matrices estáticas simples ( int[N]) y las matrices dinámicas simples ( new int[10]) no ofrecen ninguna y, por lo tanto, deben evitarse si es posible, lo que debería ser posible en la gran mayoría de los casos. Si eso no fuera suficiente, las matrices dinámicas simples tampoco ofrecen forma de consultar su tamaño, una oportunidad adicional para daños en la memoria y agujeros de seguridad.

Pueden ser la respuesta más correcta posible cuando solo puede introducir un solo puntero a través de una API existente (mensaje de ventana de pensamiento o parámetros de devolución de llamada relacionados con subprocesos) que tienen alguna medida de vida útil después de ser "atrapados" en el otro lado de la escotilla, pero que no está relacionado con el código de llamada:

unique_ptr<byte[]> data = get_some_data();

threadpool->post_work([](void* param) { do_a_thing(unique_ptr<byte[]>((byte*)param)); },
                      data.release());

Todos queremos que las cosas sean buenas para nosotros. C ++ es para las otras veces.

unique_ptr<char[]>se puede usar donde desee el rendimiento de C y la conveniencia de C ++. Considere que necesita operar con millones (ok, miles de millones si aún no confía) de cadenas. Almacenar cada uno de ellos en un objeto stringu vector<char>objeto separado sería un desastre para las rutinas de administración de memoria (montón). Especialmente si necesita asignar y eliminar diferentes cadenas muchas veces.

Sin embargo, puede asignar un único búfer para almacenar tantas cadenas. No le gustaría char* buffer = (char*)malloc(total_size);por razones obvias (si no es obvio, busque "por qué usar ptrs inteligentes"). Prefieresunique_ptr<char[]> buffer(new char[total_size]);

Por analogía, las mismas consideraciones de rendimiento y conveniencia se aplican a los no chardatos (considere millones de vectores / matrices / objetos).

• Necesita que su estructura contenga solo un puntero por razones de compatibilidad binaria.
• Debe interactuar con una API que devuelve la memoria asignada con new[]
• Su empresa o proyecto tiene una regla general contra el uso std::vector, por ejemplo, para evitar que los programadores descuidados introduzcan copias accidentalmente
• Desea evitar que los programadores descuidados introduzcan accidentalmente copias en esta instancia.

Existe una regla general de que los contenedores de C ++ deben preferirse a los suyos con punteros. Es una regla general; Tiene excepciones. Hay más; Estos son solo ejemplos.

Si necesita una matriz dinámica de objetos que no sean construibles con copia, entonces un puntero inteligente a una matriz es el camino a seguir. Por ejemplo, ¿qué pasa si necesita una matriz de atómicos?