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

class Widget { // В файле "widget.h"

public:

Widget();

… // Нет объявлений деструктора

// и перемещающих операций

private:

struct Impl;

std::shared_ptr pImpl; // std::shared_ptr

}; // вместо std::unique_ptr

и приведенном далее коде клиента, который включает заголовочный файл widget.h

Widget w1;

auto w2(std::move(w1)); // Перемещающее конструирование w2

w1 = std::move(w2); // Перемещающее присваивание w1

все компилировалось бы и работало именно так, как мы рассчитывали: w1был бы создан конструктором по умолчанию, его значение было бы перемещено в w2, а затем это значение, в свою очередь, было бы перемещено в w1, после чего и w1, и w2были бы уничтожены (тем самым приводя к уничтожению объекта Widget::Impl).

Различие в поведении указателей std::unique_ptrи std::shared_ptrдля pImplвытекает из различий путей, которыми эти интеллектуальные указатели поддерживают пользовательские удалители. Для std::unique_ptrтип удалителя является частью типа интеллектуального указателя, и это позволяет компилятору генерировать меньшие структуры данных времени выполнения и более быстрый код. Следствием этой более высокой эффективности является то, что указываемые типы должны быть полными, когда используются специальные функции-члены, генерируемые компиляторами (например, деструкторы или перемещающие операции). В случае std::shared_ptrтип удалителя не является частью типа интеллектуального указателя. Это требует больших структур данных времени выполнения и несколько более медленного кода, но зато указываемые типы не обязаны быть полными при применении специальных функций-членов, генерируемых компиляторами.

При применении идиомы Pimpl в действительности нет никакого компромисса между характеристиками std::unique_ptrи std::shared_ptr, поскольку отношения между классами наподобие Widgetи Widget::Implпредставляют собой исключительное владение, и это делает единственно верным выбором в качестве инструмента интеллектуальный указатель std::unique_ptr. Тем не менее стоит знать, что в других ситуациях — ситуациях, в которых осуществляется совместное владение (а следовательно, правильным выбором является std::shared_ptr), — нет необходимости прыгать через горящие обручи определений функций, которую влечет за собой применение std::unique_ptr.

• Идиома Pimpl уменьшает время построения приложения, снижая зависимости компиляции между клиентами и реализациями классов.

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

• Приведенный выше совет применим к интеллектуальному указателю std::unique_ptr, но не к std::shared_ptr.

На первый взгляд, семантика перемещения и прямой передачи кажется довольно простой.

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

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

Rvаluе-ссылки представляют собой тот клей, который соединяет две эти довольно разные возможности. Это базовый механизм языка программирования, который делает возможными как семантику перемещения, так и прямую передачу.

С ростом опыта работы с этими возможностями вы все больше понимаете, что ваше первоначальное впечатление было основано только на пресловутой вершине айсберга. Мир семантики перемещения, прямой передачи и rvalue-ccылoк имеет больше нюансов, чем кажется на первый взгляд. Например, std::moveничего не перемещает, а прямая передача оказывается не совсем прямой. Перемещающие операции не всегда дешевле копирования, а когда и дешевле, то не всегда настолько, как вы думаете; кроме того, они не всегда вызываются в контексте, где перемещение является корректным. Конструкция type&&не всегда представляет rvalue-ссылку.

Независимо от того, как глубоко вы закопались в эти возможности, может показаться, что можно долго копать еще глубже. К счастью, эта глубина не безгранична. Эта глава доведет вас до коренной породы. Когда вы докопаетесь до нее, эта часть С++11 будет выглядеть намного более осмысленной. Например, вы познакомитесь с соглашениями по использованию std::moveи std::forward. Вы почувствуете себя намного более комфортно, сталкиваясь с неоднозначной природой type&&. Вы поймете причины удивительно разнообразного поведения перемещающих операций. Все фрагменты мозаики встанут на свои места. В этот момент вы окажетесь там, откуда начинали, потому что семантика перемещений, прямая передача и rvalue-ссылки вновь покажутся вам достаточно простыми. Но на этот раз они будут оставаться для вас такими навсегда.

В этой главе особенно важно всегда иметь в виду, что параметр всегда является lvalue, даже если его тип — rvalue-ссылка. Иными словами, в фрагменте

void f( Widget&& w);

параметр wпредставляет собой lvalue, несмотря на то что его тип — rvalue-ссылка на Widget. (Если это вас удивляет, вернитесь к обзору lvalue и rvalue, который содержится во введении.)

Полезно подойти к std::moveи std::forwardс точки зрения того, чего они не делают . std::moveничего не перемещает. std::forwardничего не передает. Во время выполнения они не делают вообще ничего. Они не генерируют выполнимый код — ни одного байта.

std::moveи std::forwardявляются всего лишь функциями (на самом деле — шаблонами функций), которые выполняют приведения. std::moveвыполняет безусловное приведение своего аргумента к rvalue, в то время как std::forwardвыполняет приведение только при соблюдении определенных условий. Это все. Пояснения приводят к новому множеству вопросов, но, по сути, история на этом завершена.

Чтобы сделать историю более конкретной, рассмотрим пример реализации std::moveв C++11. Она не полностью соответствует деталям стандарта, но очень близка к этому.