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

Небольшое снижение производительности возникает из-за того, что в небезопасном с точки зрения исключений коде мы передавали функции processWidgetrvalue.

processWidget (

std::shared_ptr(new Widget, cusDel), // rvalue

computePriority()

);

а в случае безопасного вызова — передаем lvalue:

processWidget( spw, computePriority()); // lvalue

Поскольку параметр std::shared_ptrфункции processWidgetпередается по значению, создание из rvalueвлечет за собой только перемещение, в то время как создание из lvalue требует копирования. Для указателя std::shared_ptrразница может оказаться существенной, так как копирование std::shared_ptrтребует атомарного инкремента счетчика ссылок, в то время как перемещение std::shared_ptrне требует никаких действий со счетчиком ссылок вообще. Чтобы безопасный с точки зрения исключений код достиг уровня производительности небезопасного кода, нам надо применить std: :moveк spwдля того, чтобы превратить его в rvalue(см. раздел 5.1):

processWidget( std::move(spw ), // Эффективно и безопасно

computePriority()); // в смысле исключений

Это интересный метод, и его стоит знать, но обычно это не имеет особого значения, поскольку вы будете редко сталкиваться с причинами не использовать make-функцию. Если у вас нет убедительных причин поступать иначе, используйте make-функции.

• По сравнению с непосредственным использованием new, make-функции устраняют дублирование кода, повышают безопасность кода по отношению к исключениям и в случае функций std::make_sharedи std::allocate_sharedгенерируют меньший по размеру и более быстрый код.

• Ситуации, когда применение makе-функций неприемлемо, включают необходимость указания пользовательских удалителей и необходимость передачи инициализаторов в фигурных скобках.

• Для указателей std::shared_ptrдополнительными ситуациями, в которых применение makе-функций может быть неблагоразумным, являются классы с пользовательским управлением памятью и системы, в которых проблемы с объемом памяти накладываются на использование очень больших объектов и наличие указателей std::weak_ptr, время жизни которых существенно превышает время жизни указателей std::shared_ptr.

Если вам приходилось бороться со слишком большим временем построения приложения, вы, вероятно, знакомы с идиомой Pimpl (pointer to implementation, указатель на реализацию). Это методика, при которой вы заменяете члены-данные класса указателем на класс (или структуру) реализации, помещаете в него члены-данные, использовавшиеся в основном классе, и обращаетесь к ним опосредованно через указатель. Предположим, например, что наш Widgetимеет следующий вид:

class Widget { // В заголовочном файле "widget.h"

public:

Widget();

…

private:

std::string name;

std::vector data;

Gadget g1, g2, g3; // Gadget - некий пользовательский тип

};

Поскольку члены-данные Widgetимеют типы std::string, std::vectorи Gadget, для компиляции Widgetдолжны присутствовать соответствующие заголовочные файлы, а это означает, что клиенты Widgetдолжны включать с помощью директивы #includeзаголовочные файлы string, vectorи gadget.h. Эти заголовочные файлы увеличивают время компиляции клиентов Widget, а также делают этих клиентов зависящими от содержимого указанных заголовочных файлов. Если содержимое заголовочного файла изменяется, клиенты Widgetдолжны быть перекомпилированы. Стандартные заголовочные файлы stringи vectorменяются не слишком часто, но заголовочный файл gadget.hвполне может оказаться подвержен частым изменениям.

Применение идиомы Pimpl в С++98 могло выполняться с помощью замены членов- данных Widget обычным указателем на объявленную, но не определенную структуру:

class Widget { // Все еще в заголовочном файле "widget.h"

public:

Widget();

~Widget(); // Деструктор необходим (см. ниже)

…

private:

struct Impl; // Объявление структуры реализации

Impl *pImpl; // и указателя на нее

};

Поскольку Widgetбольше не упоминает типы std::string, std::vectorи Gadget, клиенты Widgetбольше не обязаны включать соответствующие заголовочные файлы для этих типов. Это ускоряет компиляцию, а кроме того, означает, что если что-то в заголовочных файлах будет изменено, это не затронет клиенты Widget.