Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

auto delInvmt1 = [](Investment* pInvestment)

{ // Пользовательский удалитель

makeLogEntry(pInvestment); // как лямбда-выражение

delete pInvestment; // без состояния

};

template // Возвращаемый тип имеет размер

std::unique_ptr<Investment, // Investment*

decltype(delInvmt1)>

makeInvestment(Ts&&... args);

void delInvmt2(Investment* pInvestment) // Пользовательский

{ // удалитель как

makeLogEntry(pInvestment); // функция

delete pInvestment;

}

template // Возвращаемый тип имеет размер

std::unique_ptr<Investment, // Investment* плюс как минимум

void (*)(Investment*)> // размер указателя на функцию!

makeInvestment(Ts&&... params);

Удалители в виде функциональных объектов с большим размером состояния могут привести к значительным размерам объектов std::unique_ptr. Если вы обнаружите, что пользовательский удалитель делает ваш интеллектуальный указатель std::unique_ptrнеприемлемо большим, вам, вероятно, стоит изменить свой дизайн.

Фабричные функции — не единственный распространенный способ использования std::unique_ptr. Эти интеллектуальные указатели еще более популярны в качестве механизма реализации идиомы Pimpl (указателя на реализацию). Соответствующий код не сложен, но его рассмотрение отложено до раздела 4.5, посвященного данной теме.

Интеллектуальный указатель std::unique_ptrимеет две разновидности: одну — для индивидуальных объектов ( std::unique_ptr), а другую — для массивов ( std::unique_ptr). В результате никогда не возникает неясность в том, на какую сущность указывает std::unique_ptr. API std::unique_ptrразработан так, чтобы соответствовать используемой разновидности. Например, в случае указателя для одного объекта отсутствует оператор индексирования ( operator[]), в то время как в случае указателя для массива отсутствуют операторы разыменования ( operator*и operator->).

Существование std::unique_ptrдля массивов должно представлять только интеллектуальный интерес, поскольку std::array, std::vectorи std::stringпочти всегда оказываются лучшим выбором, чем встроенные массивы. Я могу привести только одну ситуацию, когда std::unique_ptrимеет смысл — при использовании С-образного API, который возвращает встроенный указатель на массив в динамической памяти, которым вы будете владеть.

Интеллектуальный указатель std::unique_ptrпредставляет собой способ выражения исключительного владения на С++11, но одной из наиболее привлекательных возможностей является та, что его можно легко и эффективно преобразовать в std::shared_ptr:

std::shared_ptrsp = // Конвертация std: :unique_ptr

makeInvestment( arguments ); // в std::shared_ptr

Это ключевой момент, благодаря которому std::unique_ptrнастолько хорошо подходит для возвращаемого типа фабричных функций. Фабричные функции не могут знать, будет ли вызывающая функция использовать семантику исключительного владения возвращенным объектом или он будет использоваться совместно (т.e. std::shared_ptr). Возвращая std::unique_ptr, фабрики предоставляют вызывающим функциям наиболее эффективный интеллектуальный указатель, но не мешают им заменить этот указатель более гибким. (Информация об интеллектуальном указателе std::shared_ptrприведена в разделе 4.2.)

• std::unique_ptrпредставляет собой маленький, быстрый, предназначенный только для перемещения интеллектуальный указатель для управления ресурсами с семантикой исключительного владения.

• По умолчанию освобождение ресурсов выполняется с помощью оператора delete, но могут применяться и пользовательские удалители. Удалители без состояний и указатели на функции в качестве удалителей увеличивают размеры объектов std::unique_ptr.

• Интеллектуальные указатели std::unique_ptrлегко преобразуются в интеллектуальные указатели std::shared_ptr.

Программисты на языках программирования со сборкой мусора показывают пальцами на программистов на С++ и смеются над ними, потому что те озабочены предотвращением утечек ресурсов. “Какой примитив! — издеваются они. — Вы что, застряли в 1960-х годах и в Lisp? Управлять временем жизни ресурсов должны машины, а не люди”. Разработчики на С++ не остаются в долгу: “Вы имеете в виду, что единственным ресурсом является память, а время освобождения ресурса должно быть принципиально неопределимо? Спасибо, мы предпочитаем обобщенность и предсказуемость деструкторов!” Впрочем, в нашей браваде есть немного бахвальства. Сборка мусора в действительности достаточно удобна, а управление временем жизни вручную действительно может показаться похожим на создание микросхем памяти из шкуры медведя с помощью каменных ножей. Почему же не получается взять лучшее из двух миров — систему, которая работает автоматически (как сборка мусора) и к тому же применима ко всем ресурсам и имеет предсказуемое время выполнения (подобно деструкторам)?