Правило 25: Подумайте о поддержке функции swap, не возбуждающей исключений

Правило 25: Подумайте о поддержке функции swap, не возбуждающей исключений

swap – интересная функция. Изначально она появилась в библиотеке STL и с тех пор стала, во-первых, основой для написания программ, безопасных в смысле исключений (см. правило 29), а во-вторых, общим механизмом решения задачи и присваивания самому себе (см. правило 11). Раз уж swap настолько полезна, то важно реализовать ее правильно, но рука об руку с особой важностью идут и особые сложности. В этом правиле мы исследуем, что они собой представляют и как с ними бороться.

Чтобы обменять (swap) значения двух объектов, нужно присвоить каждому из них значение другого. По умолчанию такой обмен осуществляет стандартный алгоритм swap. Его типичная реализация не расходится с вашими ожиданиями:

namespace std {

template <typename T> // типичная реализация std::swap

void swap(T& a, T& b) // меняет местами значения a и b

{

T temp(a);

a = b;

b = temp;

}

}

Коль скоро тип поддерживает копирование (с помощью конструктора копирования и оператора присваивания), реализация swap по умолчанию позволяет объектам этого типа обмениваться значениями без всяких дополнительных усилий с вашей стороны.

Стандартная реализация swap, может быть, не приведет вас в восторг. Она включает копирование трех объектов: a в temp, b в a и temp – в b. Для некоторых типов ни одна из этих операция в действительности не является необходимой. Для таких типов swap по умолчанию – быстрый путь на медленную дорожку.

Среди таких типов сразу стоит выделить те, что состоят в основном из указателей на другой тип, содержащий реальные данные. Общее название для таких проектных решений: «идиома pimpl» (pointer to implementation – указатель на реализацию – см. правило 31). Спроектированный так класс Widget может быть объявлен следующим образом:

class WidgetImpl { // класс для данных Widget

public: // детали несущественны

...

private:

int a,b,c; // возможно, много данных –

std::vector<double> v; // копирование обойдется дорого

...

};

class Widget { // класс, использующий идиому pimpl

public:

Widget(const Widget& rhs);

Widget& operator=(const Widget& rhs) // чтоб скопировать Widget, копируем

{ // его объект WidgetImpl. Детали

... // реализации operator= как такового

*pimpl = *(rhs.pimpl); // см. в правилах 10, 11 и 12

...

}

...

private:

WidgetImpl *pimpl; // указатель на объект с данными

}; // этого Widget

Чтобы обменять значения двух объектов Widget, нужно лишь обменять значениями их указатели pimpl, но алгоритм swap по умолчанию об этом знать не может. Вместо этого он не только трижды выполнит операцию копирования Widget, но еще и три раза скопирует Widgetlmpl. Очень неэффективно!

А нам бы хотелось сообщить функции std::swap, что при обмене объектов Widget нужно обменять значения хранящихся в них указателей pimpl. И такой способ существует: специализировать std::swap для класса Widget. Ниже приведена основная идея, хотя в таком виде код не скомпилируется:

namespace std {

template <> // это специализированная версия

void swap<Widget>(Widget& a, // std::swap, когда T есть

Widget& b) // Widget; не скомпилируется

{

swap(a.pimpl, b.pimpl); // для обмена двух Widget просто

} // обмениваем их указатели pimpl

}

Строка «template <>» в начале функции говорит о том, что это полная специализация шаблона std::swap, а «<Widget>» после имени функции говорит о том, что это специализация для случая, когда T есть Widget. Другими словами, когда общий шаблон swap применяется к Widget, то должна быть использована эта реализация. Вообще-то не допускается изменять содержимое пространства имен std, но разрешено вводить полные специализации стандартных шаблонов (подобных swap) для созданных нами типов (например, Widget). Что мы и делаем.

Как я уже сказал, эта функция не скомпилируется. Дело в том, что она пытается получить доступ к указателям pimpl внутри a и b, а они закрыты. Мы можем объявить нашу специализацию другом класса, но соглашение требует поступить иначе: нужно объявить в классе Widget открытую функцию-член по имени swap, которая осуществит реальный обмен значениями, а затем специализация std::swap вызовет эту функцию-член:

class Widget { // все как раньше, за исключением

public: // добавления функции-члена swap

...

void swap(Widget& other)

{

using std::swap; // необходимость в этом объявлении

// объясняется далее

swap(pimpl, other.pimpl); // чтобы обменять значениями два объекта

} // Widget,обмениваем указатели pimpl

...

};

namespace std {

template <> // переделанная версия

void swap<Widget>(Widget& a, // std::swap

Widget& b)

{

a.swap(b); // чтобы обменять значениями Widget,

} // вызываем функцию-член swap

}

Этот вариант не только компилируется, но и полностью согласован с STL-контейнерами, каждый из которых предоставляет и открытую функцию-член swap, и специализированную версию std::swap, которая вызывает эту функцию-член.

Предположим, однако, что Widget и Widgetlmpl – это не обычные, а шаблонные классы. Возможно, это понадобилось для того, чтобы можно было параметризировать тип данных, хранимых в Widgetlmpl:

template <typename T>

class WidgetImpl {...};

template <typename T>

class Widget {...};

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

namespace std {

template <typename T>

void swap<Widget<T>>(Widget<T>& a, // ошибка! Недопустимый код

Widget<T>& b)

{ a.swap(b);}

}

Выглядит совершенно разумно, но все равно неправильно. Мы пытаемся частично специализировать шаблон функции (std::swap), но, хотя C++ допускает частичную специализацию шаблонов класса, он не разрешает этого для шаблонов функций. Этот код не должен компилироваться (если только некоторые компиляторы не пропустят его по ошибке).

Когда вам нужно «частично специализировать» шаблон функции, лучше просто добавить перегруженную версию. Примерно так:

namespace std {

template <typename T>

void swap(Widget<T>& a, // перегрузка std::swap

Widget<T>& b) // (отметим отсутствие <...> после

{ a.swap(b);} // “swap”), далее объяснено, почему

} // этот код некорректен

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

Что же делать? Нам по-прежнему нужен способ, чтобы разрешить другим людям вызывать swap и иметь более эффективную шаблонную версию. Ответ прост. Мы, как и раньше, объявляем свободную функцию swap, которая вызывает функцию-член swap, но не говорим, что это специализация или перегруженный вариант std::swap. Например, если вся функциональность, касающаяся Widget, находится в пространстве имен WidgetStuff, то это будет выглядеть так:

namespace WidgetStuff {

... // шаблонный WidgetImpl и т. п.

template<typename T> // как и раньше, включая

class Widget {...}; // функцию-член swap

...

template<typename T> // свободная функция swap

void swap(Widget<T>& a, // не входит в пространство имен std

Widget<T>& b)

{

a.swap(b);

}

}

Теперь если кто-то вызовет swap для двух объектов Widget, то согласно правилам поиска имен в C++ (а точнее, согласно правилу учета зависимостей от аргументов) будет найдена специфичная для Widget версия в пространстве имен WidgetStuff. А это как раз то, что мы хотим.

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

Кстати, если вы не пользуетесь пространствам имен, все вышесказанное остается в силе (то есть вам нужна свободная функция swap, которая вызывает функцию-член swap). Но зачем засорять глобальное пространство имен вашими классами, шаблонами, функциями, перечислениями и перечисляемыми константами, определениями типов typedef? Разве вы не имеете понятия о приличиях?

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

template <typename T>

void doSomething(T& obj1, T& obj2)

{

...

swap(obj1, obj2);

...

}

Какая версия swap должна здесь вызываться? Общая – из пространства std, о существовании которой вы точно знаете; ее специализация главного из std, которая может, существует, а может, нет; или специфичная для класса T, существование которой также под вопросом и которая может находиться в каком-то пространстве имен (но заведомо не в std)? Вам хотелось бы вызвать специфичную для T версию, если она существует, а в противном случае к общей версии из std. Вот как удовлетворить это желание:

template <typename T>

void doSomething(T& obj1, T& obj2)

{

using std::swap; // сделать std::swap доступной этой функции

...

swap(obj1, obj2); // вызвать лучший вариант swap для объектов типа T

...

}

Когда компилятор встречает вызов swap, он ищет, какую версию вызвать. Правила разрешения имен в C++ гарантируют, что будет найдена любая специфичная для типа T версия в глобальной области видимости или в том же пространстве имен, что и T. (Например, если T – это Widget в пространстве имен Widget-Stuff, компилятор проанализирует аргументы и найдет именно эту версию.) Если же версии swap, специфичной для T, не существует, то компилятор возьмет swap из std благодаря объявлению using, которая делает std::swap видимой. Но даже в этом случае компилятор предпочтет специализацию std::swap для типа T общему шаблону.

Таким образом, заставить компилятор вызвать нужную вам версию swap достаточно просто. Единственное, о чем следует позаботиться, – не квалифицировать вызов именем пространства имен, потому что это влияет на способ выбора функции. Например, если вы напишете вызов следующим образом:

std::swap(obj1, obj2): // неправильный способ вызова swap

то заставите компилятор рассматривать только swap из пространства std (включая все специализации шаблонов), исключив возможность отыскания более подходящей версии, специфичной для типа T, даже если она где-то определена. К сожалению, некоторые программисты по ошибке квалифицируют вызов swap таким образом, поэтому важно предоставлять в своем классе полную специализацию std::swap, тогда даже в таком, неправильно написанном коде специфичная для типа реализация swap окажется доступной. (Подобный код присутствует в некоторых реализациях стандартной библиотеки, поэтому в ваших интересах – сделать все, чтобы он работал эффективно).

Итак, мы обсудили реализацию swap по умолчанию, в виде функции-члена класса, в виде свободной функции и в виде специализации std::swap, а также вызовы swap. Теперь подведем итоги.

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

Во-вторых, если реализация по умолчанию swap недостаточно эффективна (что почти всегда означает, что ваш класс или шаблон использует некоторую вариацию идиомы pimpl), сделайте следующее:

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

2) предоставьте свободную функцию swap в том же пространстве имен, что и ваш класс или шаблон. Пусть она вызывает вашу функцию-член;

3) если вы пишете класс (а не шаблон), специализируйте std::swap для вашего класса. Пусть она также вызывает вашу функцию-член.

Наконец, если вы вызываете swap, убедитесь, что включено using-объявление, которое вводит std::swap в область видимости вашей функции, а затем вызывайте swap без квалификации пространства имен.

Я еще забыл предупредить, что версия функции-члена swap никогда не должна возбуждать исключений. Дело в том, что одно из наиболее частых применений swap – помочь классам (и шаблонам классов) в предоставлении надежных гарантий безопасности исключений. В правиле 29 вы найдете подробную информацию на эту тему, а сейчас лишь подчеркнем, что в основе этого приема лежит предположение о том, что swap, реализованная в виде функции-члена, никогда не возбуждает исключений. Это ограничение касается только функции-члена! Оно не относится к реализации swap в виде свободной функции, поскольку стандартная версия swap по умолчанию основана на конструкторах копирования и операторе присваивания, а этим функциям разрешено возбуждать исключения. Когда вы пишете собственную версию swap, то обычно представляете не просто эффективный способ обмена значений, а такой, при котором не возбуждаются исключения. Общее правил таково: эти две характеристики swap идут рука об руку, потому что высокоэффективные операции обмена всегда основаны на операциях над встроенными типами (такими как указатели, лежащие в основе идиомы pimpl), а операции над встроенными типами никогда не возбуждают исключений.

Что следует помнить

• Предоставьте функцию-член swap, если std::swap работает с вашим типом неэффективно. Убедитесь, что она не возбуждает исключений.

• Если вы предоставляете функцию-член swap, то также предоставьте свободную функцию, вызывающую функцию-член. Для классов (не шаблонов) специализируйте также std::swap.

• Когда вызывается swap, используйте using-объявление, вводящее std::swap в область видимости, и вызывайте swap без квалификатора пространства имен.

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

Данный текст является ознакомительным фрагментом.



Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

54. Избегайте срезки. Подумайте об использовании в базовом классе клонирования вместо копирования

Из книги автора

54. Избегайте срезки. Подумайте об использовании в базовом классе клонирования вместо копирования РезюмеСрезка объектов происходит автоматически, невидимо и может приводить к полному разрушению чудесного полиморфного дизайна. Подумайте о полном запрете копирующего


Правило 5: Какие функции C++ создает и вызывает молча

Из книги автора

Правило 5: Какие функции C++ создает и вызывает молча Когда пустой класс перестает быть пустым? Когда за него берется C++. Если вы не объявите конструктор копирования, оператор присваивания или деструктор самостоятельно, то компилятор сделает это за вас. Более того, если вы


Правило 6: Явно запрещайте компилятору генерировать функции, которые вам не нужны

Из книги автора

Правило 6: Явно запрещайте компилятору генерировать функции, которые вам не нужны Агенты по продаже недвижимости и программные системы, обслуживающие их деятельность, могут нуждаться в классе, представляющем дома, выставленные на продажу:class HomeForSale {...};Любой агент по


Правило 9: Никогда не вызывайте виртуальные функции в конструкторе или деструкторе

Из книги автора

Правило 9: Никогда не вызывайте виртуальные функции в конструкторе или деструкторе Начну с повторения: вы не должны вызывать виртуальные функции во время работы конструкторов или деструкторов, потому что эти вызовы будут делать не то, что вы думаете, и результатами их


Правило 23: Предпочитайте функциям-членам функции, не являющиеся ни членами, ни друзьями класса

Из книги автора

Правило 23: Предпочитайте функциям-членам функции, не являющиеся ни членами, ни друзьями класса Возьмем класс для представления Web-браузера. В числе прочих такой класс может предлагать функции, который очищают кэш загруженных элементов, очищают историю посещенных URL и


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

Из книги автора

Правило 24: Объявляйте функции, не являющиеся членами, когда преобразование типов должно быть применимо ко всем параметрам Во введении я отмечал, что в общем случае поддержка классом неявных преобразований типов – неудачная мысль. Но, конечно, из этого правила есть


Правило 29: Стремитесь, чтобы программа была безопасна относительно исключений

Из книги автора

Правило 29: Стремитесь, чтобы программа была безопасна относительно исключений Безопасность исключений в чем-то подобна беременности… но пока отложим эту мысль в сторонку. Нельзя всерьез говорить о репродуктивной функции, пока не завершился этап ухаживания.Предположим,


Правило 36: Никогда не переопределяйте наследуемые невиртуальные функции

Из книги автора

Правило 36: Никогда не переопределяйте наследуемые невиртуальные функции Предположим, я сообщаю вам, что класс D открыто наследует классу B и что в классе B определена открытая функция-член mf. Ее параметры и тип возвращаемого значения не важны, поэтому давайте просто


Правило 37: Никогда не переопределяйте наследуемое значение аргумента функции по умолчанию

Из книги автора

Правило 37: Никогда не переопределяйте наследуемое значение аргумента функции по умолчанию Давайте с самого начала упростим обсуждение. Есть только два типа функций, которые можно наследовать: виртуальные и невиртуальные. Но переопределять наследуемые невиртуальные


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

Из книги автора

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


Обменять (Swap)

Из книги автора

Обменять (Swap) template ‹class T›void swap(T& a, T& b);swap обменивает значения, хранимые в двух местах.template ‹class ForwardIterator1, class ForwardIterator2›void iter_swap(ForwardIterator1 a, ForwardIterator2 b);iter_swap обменивает значения, указанные двумя итераторами a и b.tempate ‹class ForwardIterator1, class ForwardIterator2›ForwardIterator2 swap_ranges(ForwardIterator1


11.4.1. Спецификации исключений и указатели на функции

Из книги автора

11.4.1. Спецификации исключений и указатели на функции Спецификацию исключений можно задавать и при объявлении указателя на функцию.Например:void (*pf)( int ) throw(string);В этом объявлении говорится, что pf указывает на функцию, которая способна возбуждать только исключения типа string.


Серьезное отношение к поддержке безопасности

Из книги автора

Серьезное отношение к поддержке безопасности Администрирование брандмауэра является серьезной работой. Она должна восприниматься серьезно и администратором, и его начальником. Global Chips не имела крепкой брони, чтобы отразить угрозы для их информации. В любое время хакер