Есть ли какое-либо использование для unique_ptr с массивом?

std::unique_ptr имеет поддержку массивов, например:

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

но нужно ли это? Вероятно, это более удобно для использования std::vectorили std::array.

Нашли ли вы какую-либо пользу для этой конструкции?

Некоторые люди не могут себе позволить пользоваться std::vectorдаже распределителями. Некоторым людям нужен динамически изменяемый массив, поэтому std::arrayего нет. И некоторые люди получают свои массивы из другого кода, который, как известно, возвращает массив; и этот код не будет переписан, чтобы вернуть vectorили что-то.

Позволяя unique_ptr<T[]>, вы обслуживаете эти потребности.

Короче говоря, вы используете, unique_ptr<T[]>когда вам нужно . Когда альтернативы просто не будут работать на вас. Это инструмент последней инстанции.

Есть компромиссы, и вы выбираете решение, которое соответствует тому, что вы хотите. С верхней части моей головы:

Начальный размер

• vectorи unique_ptr<T[]>позвольте размеру быть определенным во время выполнения
• array только позволяет указать размер во время компиляции

Изменение размера

• arrayи unique_ptr<T[]>не разрешать изменение размера
• vector делает

Место хранения

• vectorи unique_ptr<T[]>хранить данные вне объекта (обычно в куче)
• array хранит данные непосредственно в объекте

Копирование

• arrayи vectorразрешить копирование
• unique_ptr<T[]> не позволяет копировать

Обмен / ход

• vectorи unique_ptr<T[]>иметь O (1) время swapи операции перемещения
• arrayимеет O (n) время swapи операции перемещения, где n - количество элементов в массиве

Недействительный указатель / ссылка / итератор

• array гарантирует, что указатели, ссылки и итераторы никогда не будут признаны недействительными, пока объект активен, даже если swap()
• unique_ptr<T[]>не имеет итераторов; указатели и ссылки становятся недействительными, только если swap()объект активен. (После замены указатели указывают на массив, с которым вы меняли местами, поэтому они все еще «действительны» в этом смысле.)
• vector может аннулировать указатели, ссылки и итераторы при любом перераспределении (и предоставляет некоторые гарантии, что перераспределение может произойти только при определенных операциях).

Совместимость с концепциями и алгоритмами

• arrayи vectorоба контейнера
• unique_ptr<T[]> это не контейнер

Я должен признать, что это похоже на возможность некоторого рефакторинга с дизайном на основе политик.

Одна из причин, по которой вы можете использовать a, unique_ptrзаключается в том, что вы не хотите оплачивать стоимость выполнения инициализации массива.

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

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

std::vectorКонструктор и std::vector::resize()оценит инициализирует T- но newне будет делать, если Tэто POD.

Смотрите Value-Initialized Objects в C ++ 11 и конструктор std :: vector

Обратите внимание, что vector::reserveздесь нет альтернативы: доступ к необработанному указателю после std :: vector :: reserve безопасен?

Это та же причина , программист C может выбрать mallocболее calloc.

std::vectorМогут быть скопированы вокруг, в то время как unique_ptr<int[]>позволяет выразить уникальное владение массива. std::arrayс другой стороны, требует, чтобы размер был определен во время компиляции, что может быть невозможно в некоторых ситуациях.

Скотт Мейерс говорит об этом в Effective Modern C ++

Существование std::unique_ptrдля массивов должны быть только интеллектуальный интерес к вам, потому что std::array, std::vector, std::stringпрактически всегда выбор лучше структур данных , чем сырые массивы. Об единственной ситуации, которую я могу себе представить, когда std::unique_ptr<T[]>смысл имеет смысл, когда вы используете C-подобный API, который возвращает необработанный указатель на массив кучи, владельцем которого вы являетесь.

Я думаю, что ответ Чарльза Сальвии важен: это std::unique_ptr<T[]>единственный способ инициализировать пустой массив, размер которого неизвестен во время компиляции. Что бы сказал Скотт Мейерс об этой мотивации для использования std::unique_ptr<T[]>?

В отличие от std::vectorи std::array, std::unique_ptrможет иметь нулевой указатель.
Это удобно при работе с C API, которые ожидают либо массив, либо 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());
}

Я использовал unique_ptr<char[]>для реализации предварительно выделенных пулов памяти, используемых в игровом движке. Идея состоит в том, чтобы предоставить предварительно распределенные пулы памяти, используемые вместо динамических распределений для возврата результатов запросов на столкновения и других вещей, таких как физика элементарных частиц, без необходимости выделять / освобождать память в каждом кадре. Это довольно удобно для таких сценариев, когда вам нужны пулы памяти для выделения объектов с ограниченным сроком службы (обычно один, 2 или 3 кадра), которые не требуют логики уничтожения (только освобождение памяти).

Общий шаблон можно найти в некоторых вызовах Windows Win32 API , в которых использование std::unique_ptr<T[]>может оказаться полезным, например, когда вы точно не знаете, насколько большим должен быть выходной буфер при вызове некоторого Win32 API (который будет записывать некоторые данные внутри этот буфер):

// 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...
...

Я столкнулся со случаем, когда мне пришлось использовать std::unique_ptr<bool[]>, который был в библиотеке HDF5 (библиотека для эффективного хранения двоичных данных, много использованная в науке). Некоторые компиляторы (в моем случае Visual Studio 2015) обеспечивают сжатиеstd::vector<bool> (используя 8 bools в каждом байте), что является катастрофой для чего-то вроде HDF5, который не заботится об этом сжатии. При этом std::vector<bool>HDF5 в конечном итоге считывал мусор из-за этого сжатия.

Угадайте, кто был там для спасения, в случае, когда std::vectorне сработало, и мне нужно было аккуратно выделить динамический массив? :-)

В двух словах: это наиболее эффективная память.

A std::stringпоставляется с указателем, длиной и буфером «оптимизации коротких строк». Но в моей ситуации мне нужно хранить строку, которая почти всегда пуста, в структуре, которой у меня сотни тысяч. В С я бы просто использовал char *, и большую часть времени он был бы нулевым. Это также работает для C ++, за исключением того, что a char *не имеет деструктора и не знает, как удалить себя. Напротив, a std::unique_ptr<char[]>удалит себя, когда выйдет из области видимости. Пустой std::stringзанимает 32 байта, но пустой std::unique_ptr<char[]>занимает 8 байтов, то есть точно размер его указателя.

Самым большим недостатком является то, что каждый раз, когда я хочу узнать длину строки, мне приходится обращаться strlenк ней.

Чтобы ответить тем, кто думает, что вы «должны» использовать vectorвместо « unique_ptrУ меня есть случай программирования CUDA на GPU», когда вы выделяете память в Device, вы должны использовать массив указателей (с cudaMalloc). Затем, при получении этих данных в Host, вы должны снова пойти за указателем, и unique_ptrвы можете легко справиться с указателем. За дополнительной платой преобразования double*в vector<double>ненужно и приводит к потере перфорации.

Еще одна причина разрешить и использовать std::unique_ptr<T[]>, которая не была упомянута в ответах до сих пор: она позволяет вам заранее объявить тип элемента массива.

Это полезно, когда вы хотите минимизировать связанные #includeоператоры в заголовках (чтобы оптимизировать производительность сборки).

Например -

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

С вышеупомянутой структурой кода любой может #include "myclass.h"и может использовать MyClass, не включая внутренние зависимости реализации, требуемые MyClass::m_InternalArray.

Если m_InternalArrayвместо этого было объявлено как a std::array<ALargeAndComplicatedClassWithLotsOfDependencies>или a std::vector<...>, соответственно - результатом будет попытка использования неполного типа, что является ошибкой во время компиляции.

Я не могу не согласиться с духом принятого ответа достаточно сильно. «Инструмент последней инстанции»? Отнюдь не!

На мой взгляд, одна из самых сильных возможностей C ++ по сравнению с C и некоторыми другими подобными языками - это способность выражать ограничения, чтобы их можно было проверять во время компиляции и предотвратить случайное неправильное использование. Поэтому при проектировании структуры спросите себя, какие операции она должна разрешать. Все другие виды использования должны быть запрещены, и лучше всего, если такие ограничения могут быть реализованы статически (во время компиляции), чтобы неправильное использование приводило к ошибке компиляции.

Поэтому, когда нужен массив, ответы на следующие вопросы определяют его поведение: 1. Является ли его размер a) динамическим во время выполнения, или b) статическим, но известным только во время выполнения, или c) статичным и известным во время компиляции? 2. Можно ли разместить массив в стеке или нет?

И, исходя из ответов, это то, что я считаю лучшей структурой данных для такого массива:

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

Да, я думаю, что unique_ptr<std::array>также следует учитывать, и ни один из них не является последним средством. Подумайте, что лучше всего подходит для вашего алгоритма.

Все они совместимы с простыми API C через необработанный указатель на массив данных ( vector.data()/ array.data()/ uniquePtr.get()).

PS Помимо вышеизложенных соображений, есть и право собственности: std::arrayи они std::vectorимеют семантику значения (имеют встроенную поддержку копирования и передачи по значению), но unique_ptr<T[]>могут быть перемещены только (обеспечивает единоличное владение). Любой может быть полезен в различных сценариях. Напротив, простые статические массивы ( int[N]) и простые динамические массивы ( new int[10]) не предлагают ни одного, и поэтому их следует избегать, если это возможно, - что должно быть возможно в подавляющем большинстве случаев. Если этого было недостаточно, обычные динамические массивы также не дают возможности запрашивать их размер - дополнительная возможность для повреждений памяти и дыр в безопасности.

Они могут быть самым правильным ответом из всех возможных, когда вы получаете только один указатель через существующий API (параметры окна сообщения или параметры обратного вызова, связанного с потоками), которые имеют некоторую меру времени жизни после того, как их «поймали» на другой стороне штриховки, но который не связан с вызывающим кодом:

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

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

Мы все хотим, чтобы все было хорошо для нас. С ++ для другого времени.

unique_ptr<char[]>можно использовать там, где вы хотите производительность C и удобство C ++. Учтите, что вам нужно оперировать миллионами (ну, миллиардами, если вы еще не доверяете) строк. Хранение каждого из них в отдельном объекте stringили vector<char>объекте было бы катастрофой для процедур управления памятью (кучей). Особенно, если вам нужно выделить и удалить разные строки много раз.

Однако вы можете выделить один буфер для хранения такого количества строк. Вам не понравится char* buffer = (char*)malloc(total_size);по понятным причинам (если не очевидно, поиск «зачем использовать умные ptrs»). Вы бы предпочлиunique_ptr<char[]> buffer(new char[total_size]);

По аналогии, те же соображения производительности и удобства применимы к не- charданным (рассмотрим миллионы векторов / матриц / объектов).

• Ваша структура должна содержать только указатель по причинам совместимости с двоичными файлами.
• Вы должны взаимодействовать с API, который возвращает память, выделенную с new[]
• У вашей фирмы или проекта есть общее правило std::vector, запрещающее использование , например, предотвращения случайного введения копий неосторожными программистами.
• Вы хотите, чтобы неосторожные программисты случайно не вводили копии в этом случае.

Существует общее правило, что контейнеры C ++ предпочтительнее, чем использование собственных указателей. Это общее правило; у него есть исключения. Есть еще кое-что; это всего лишь примеры.

Если вам нужен динамический массив объектов, которые не поддаются копированию, то разумный указатель на массив - это путь. Например, что если вам нужен массив атомиков.