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

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

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

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

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

...

}

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

for(int i=0; i

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

...

}

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

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

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

• Подход B: n конструкторов + n деструкторов

Для классов, в которых стоимость операции присваивания меньше, чем пары конструктор-деструктор, подход A обычно более эффективен. Особенно это верно, когда значение n достаточно велико. В противном случае, возможно, подход B лучше. Более того, в случае A имя w видимо в более широкой области (включающей в себя цикл), чем в случае B, а иногда это делает программу менее понятной и удобной для сопровождения. Поэтому если (1) нет априорной информации о том, что присваивание обходится дешевле, чем пара конструктор-деструктор, и (2) речь идет о части программы, производительность которой критична, то по умолчанию рекомендуется использовать подход B.

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

• Откладывайте определение переменных насколько возможно. Это делает программы яснее и повышает их эффективность.

Правило 27: Не злоупотребляйте приведением типов

Правила C++ разработаны так, чтобы неправильно работать с типами было невозможно. Теоретически, если ваша программа компилируется без ошибок, значит, она не пытается выполнить никаких небезопасных или бессмысленных операций с объектами. Это ценная гарантия. Не надо от нее отказываться.

К сожалению, приведения обходят систему типов. И это может привести к различным проблемам, некоторые из которых распознать легко, а некоторые – чрезвычайно трудно. Если вы пришли к C++ из мира C, Java или C#, примите эток сведению, поскольку в указанных языках в приведениях типов чаще возникает необходимость, и они менее опасны, чем в C++. Но C++ – это не C. Это не Java. Это не C#. В этом языке приведение – это средство, к которому нужно относиться с должным почтением.

Начнем с обзора синтаксиса операторов приведения типов, потому что существует три разных способа написать одно и то же. Приведение в стиле C выглядит так:

(T) expression // привести expression к типу T

Функциональный синтаксис приведения таков:

T( expression) // привести expression к типу T

Между этими двумя формами нет ощутимого различия, просто скобки расставляются по-разному. Я называю эти формы приведениями в старом стиле.