Чи є якесь використання унікального_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[]> не є контейнером

Я маю визнати, це виглядає як можливість для деякого рефакторингу, розробленого на основі політики.

Однією з причин, яку ви можете використовувати, 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.

Дивіться об'єкти, ініціалізовані значенням у C ++ 11 та std :: конструкторі вектор

Зауважте, що vector::reserveтут не є альтернативою: чи безпечний доступ до необмеженого покажчика після std :: vector :: резерв?

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

Копіювати std::vectorможна навколо, при цьому unique_ptr<int[]>дозволяє висловити унікальну власність на масив. std::arrayз іншого боку, вимагає визначати розмір під час компіляції, що може бути неможливим у деяких ситуаціях.

Скотт Меєрс має це сказати в «Ефективних сучасних C ++»

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

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

Всупереч std::vectorі std::array, std::unique_ptrможе володіти вказівником NULL.
Це стане в нагоді при роботі з API 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 кадри), які не потребують логіки знищення (лише оперативність пам'яті).

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

// 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 булів у кожному байті), що є катастрофою для чогось типу HDF5, що не хвилює цього стиснення. З std::vector<bool>, HDF5 зрештою читав сміття через це стиснення.

Здогадайтесь, хто там був для порятунку, якщо справа std::vectorне працювала, і мені потрібно було чітко виділити динамічний масив? :-)

Коротше кажучи: це далеко не найефективніша пам'ять.

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

Найбільшим недоліком є ​​те, що кожного разу, коли я хочу знати довжину струни, мені доводиться дзвонити strlenна неї.

Щоб відповісти людям, які думають, що ви «повинні» використовувати vectorзамість unique_ptrмене, у мене є випадок програмування CUDA на графічному процесорі, коли ви виділяєте пам’ять в «Пристрій», ви повинні перейти до масиву вказівників (з 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. Чи є його розмір а) динамічним під час виконання, або б) статичним, але відомим лише під час виконання, або с) статичним і відомим під час компіляції? 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 API через необроблений вказівник на масив даних ( 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());

Ми всі хочемо, щоб речі були приємними для нас. C ++ - це для інших часів.

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 ++ слід віддати перевагу перед власними прокатками з покажчиками. Це загальне правило; вона має винятки. Є більше; це лише приклади.

Якщо вам потрібен динамічний масив об'єктів, які не можуть бути сконфігуровані копією, то розумний вказівник на масив - це шлях. Наприклад, що робити, якщо вам потрібен масив атомів.