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

Но в данном случае старый пароль (“Supercalifragilisticexpialidocious”) длиннее нового (“Beware the Jabberwock”), так что нет необходимости в выделении и освобождении памяти вовсе. Если бы использовался подход с перегрузкой, вероятно, никакие выделения и освобождения не выполнялись бы:

class Password {

public:

…

void changeTo( const std::string& newPwd) // Перегрузка для

{ // lvalue

text = newPwd; // При text.capacity() >= newPwd.size()

// можно использовать память text

}

…

private:

std::string text; // Как выше

};

В этом сценарии стоимость передачи по значению включает дополнительное выделение и освобождение памяти — стоимость, которая, скорее всего, превысит стоимость операции по перемещению std::stringна порядки.

Интересно, что если старый пароль короче нового, то обычно невозможно избежать при присваивании действий по выделению и освобождению памяти, и в этом случае передача по значению будет выполняться практически с той же скоростью, что и передача по ссылке. Таким образом, стоимость копирования параметров с помощью присваивания может зависеть от объектов, участвующих в присваивании! Этот вид анализа применим к любому типу параметров, который хранит данные в динамически выделенной памяти. Не все типы таковы, но многие — включая std::stringи std::vector— обладают этим свойством.

Это потенциальное увеличение стоимости в общем случае применимо только к передаче аргументов, являющихся lvalue, поскольку необходимость выделения и освобождения памяти обычно возникает только тогда, когда выполняется истинное копирование (не перемещение). В случае rvalue-аргументов перемещений почти всегда достаточно.

Получается, что дополнительная стоимость передачи по значению (по сравнению с передачей по ссылке) для функций, копирующих параметр с использованием присваивания, зависит от передаваемого типа, соотношения lvalue- и rvalue-аргументов и от того, использует ли тип динамическую память (и, если использует, то от реализации операторов присваивания для данного типа и вероятности того, что память, связанная с целевым объектом присваивания, как минимум того же размера, что и память присваиваемого объекта). В случае std::stringона также зависит от того, использует ли реализация оптимизацию малых строк (SSO; см. раздел 5.7), и если использует, то помещаются ли присваиваемые значения в буфер SSO.

Так что, как я говорил, при копировании параметров с помощью присваивания анализ стоимости передачи по значению становится весьма сложным. Обычно наиболее практичный подход состоит в стратегии презумпции виновности (“виновен, пока не доказано иное”), в соответствии с которым вы используете перегрузку или универсальную ссылку, а не передачу по значению, пока не будет показано, что передача по значению дает приемлемо эффективный код для используемого вами типа параметра.

Итак, для программного обеспечения, которое должно быть насколько это возможно быстрым, передача по значению может оказаться неподходящей стратегией, поскольку важным может быть даже устранение дешевых перемещений. Кроме того, не всегда понятно, сколько же перемещений имеют место на самом деле. В примере Widget::addNameпередача по значению приводит только к одной лишней операции перемещения; однако предположим, что Widget::addNameвызывает Widget::validateName, в которую параметр также передается по значению. (Возможно, имеется причина для того, чтобы всегда копировать параметр, например, для хранения его в структуре данных всех проверенных значений.) Предположим также, что функция validateNameвызывает третью функцию с передачей ей параметра по значению…

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

Есть еще одно соображение, не имеющее отношения к производительности, но которое стоит иметь в виду. Передача по значению, в отличие от передачи по ссылке, подвержена проблеме срезки . Эта проблема хорошо известна в С++98 и многократно проанализирована во множестве книг, так что я не буду подробно на ней останавливаться. Но если вам нужна функция, которая должна принимать параметры типа базового класса и любых производных от него типов , то вы не должны объявлять параметр этого типа как передаваемый по значению, так как при этом будут “срезаться” характеристики объекта производного класса, передаваемого функции:

class Widget { … }; // Базовый класс

class SpecialWidget: public Widget { … }; // Производный класс

void processWidget( Widgetw); // Функция для любого вида Widget,

// включая производные типы;

… // подвержена проблеме срезки

SpecialWidget sw;

…

processWidget(sw); // processWidget видит Widget,

// а не SpecialWidget!

Если вы не знакомы с проблемой срезки, поищите информацию в Интернете или поинтересуйтесь у друзей; информации о ней предостаточно. Вы узнаете, что срезка — это еще одна причина (помимо проблемы эффективности), по которой передача по значению имеет такую плохую репутацию в С++98. Как видите, имеются веские причины для того, чтобы вбивать в головы новичкам в программировании на С++: не передавайте объекты пользовательских типов по значению!

С++11 не отменяет мудрость С++98, касающуюся передачи по значению. В общем случае передача по значению по-прежнему влечет за собой снижение производительности, которого следует избегать, и по-прежнему может приводить к срезке. Новым в С++11 является различие аргументов, являющихся lvalue и rvalue. Реализация функций, которые используют преимущества семантики перемещения для rvalue копируемых типов, требует либо перегрузки, либо применения универсальных ссылок, и оба эти подхода имеют свои недостатки. В частном случае копируемых легко перемещаемых типов, передаваемых в функцию, которая всегда их копирует и где срезка не является проблемой, передача по значению может быть простой в реализации альтернативой, почти столь же эффективной, как и ее конкуренты с передачей по ссылке, но при этом не отягощенной их недостатками.

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

• Для lvalue-apryмeнтoв передача по ссылке (например, копирующее конструирование), за которой следует перемещающее присваивание, может оказаться существенно более дорогостоящей, чем передача по ссылке с последующим копирующим присваиванием.