Читать онлайн «Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ». Страница 31

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 что-либо новое.

В основном разработка программы сводится к написанию определений классов (и шаблонов классов) и объявлений функций (и шаблонов функций). Если сделать это правильно, то реализация уже не так сложна. Однако на некоторые моменты все же стоит обратить внимание. Слишком раннее определение переменных может отрицательно повлиять на производительность. Чрезмерное применение приведений типов также приводит к появлению медленно работающей программы, которую нелегко сопровождать и в которой могут быть трудноуловимые ошибки. Возврат дескрипторов внутренних данных объекта может нарушить принципы инкапсуляции и привести к появлению «висячих дескрипторов». Если не принимать во внимание исключения, результатом может стать утечка ресурсов и повреждение структур данных. Злоупотребление встроенными функциями приводит к «разбуханию» кода. Большое количество зависимостей между различными частями программы ведет к неприемлемо большим затратам времени на сборку программ.

Всякий раз при объявлении переменной, принадлежащий типу, в котором есть конструктор или деструктор, программа тратит время на ее конструирование, когда поток управления достигнет определения переменной, и на уничтожение – при выходе переменной из области видимости. Эти накладные расходы приходится нести даже тогда, когда переменная не используется, и, разумеется, их хотелось бы избежать.

Вероятно, вы думаете, что никогда не объявляете неиспользуемых переменных, но так ли это? Рассмотрим следующую функцию, которая возвращает зашифрованный пароль при условии, что его длина не меньше некоторого минимума. Если пароль слишком короткий, функция возбуждает исключение типа logic_error, определенное в стандартной библиотеке C++ (см. правило 54):

// эта функция объявляет переменную encrypted слишком рано

std::string encryptPassword(const std::string& password)

{

using namespace std;

string encrypted;

if(password.length() < MinimumPasswordLength) {

throw logic_error(“Слишком короткий пароль”);

}

... // сделать все, что необходимо для помещения

// зашифрованного пароля в переменную encrypted

return encrypted;

}

Нельзя сказать, что объект encrypted в этой функции совсем уж не используется, но он не используется в случае, когда возбуждается исключение. Другими словами, вы платите за вызов конструктора и деструктора объекта encrypted, даже если функция encryptPassword возбуждает исключение. Так не лучше ли отложить определение переменной encrypted до того момента, когда вы будете знать, что она нужна?

// в этой функции определение переменной encrypted отложено до момента,

// когда в ней возникает надобность

std::string encryptPassword(const std::string& password)

{

using namespace std;

if(password.length() < MinimumPasswordLength) {

throw logic_error(“Слишком короткий пароль”);

}

string encrypted;

... // сделать все, что необходимо для помещения

// зашифрованного пароля в переменную encrypted

return encrypted;

}

Этот код все еще не настолько компактный, как мог бы быть, потому что переменная encrypted определена без начального значения. А значит, будет использован ее конструктор по умолчанию. Часто первое, что нужно сделать с объектом, – это дать ему какое-то значение, нередко посредством присваивания. В правиле 4 объяснено, почему конструирование объектов по умолчанию с последующим присваиванием значения менее эффективно, чем инициализация нужным значением с самого начала. Это относится и к данному случаю. Например, предположим, что для выполнения «трудной» части работы функция encryptPassword вызывает следующую функцию:

void encrypt(std::string& s); // шифрует s по месту

Тогда encryptPassword может быть реализована следующим образом, хотя и это еще не оптимальный способ:

// в этой функции определение переменной encrypted отложено до момента,

// когда в ней возникает надобность, но и этот вариант еще недостаточно

// эффективен

std::string encryptPassword(const std::string& password)

{

... // проверка длины

string encrypted; // конструктор по умолчанию

encrypted = password; // присваивание encrypted

encrypt(encrypted);

return encrypted;

}

Еще лучше инициализировать encrypted параметром password, избежав таким образом потенциально дорогостоящего конструктора по умолчанию:

// а это оптимальный способ определения и инициализации encrypted

std::string encryptPassword(const std::string& password)

{

... // проверка длины

string encrypted(password); // определение и инициализация

// конструктором копирования

encrypt(encrypted);

return encrypted;

}

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

«А как насчет циклов?» – можете удивиться вы. Если переменная используется только внутри цикла, то что лучше: определить ее вне цикла и выполнять присваивание на каждой итерации или определить ее внутри цикла? Другими словами, какая из следующих конструкций предпочтительнее?

// Подход A: определение вне цикла

Widget w;

for(int i=0; i<n; ++i) {

w = некоторое значение, зависящее от i;

...

}

// Подход B: определение внутри цикла

for(int i=0; i<n; ++i) {

Widget w(некоторое значение, зависящее от i);

...

}

Здесь я перехожу от объекта типа string к объекту типа Widget, чтобы избежать любых предположений относительно стоимости конструирования, разрушения и присваивания.

В терминах операций Widget накладные расходы вычисляются так:

• Подход A: 1 конструктор + 1 деструктор + n присваиваний