Использование const CString & вместо CString в качестве параметра функции имеет какой-либо выигрыш в производительности? - PullRequest
0 голосов
/ 07 января 2019

У меня есть функция, которая принимает CString в качестве одного из параметров, и я просматривал базу кода, и во многих местах вместо const CString& используется аргумент.

Итак, я хочу знать, есть ли разница в производительности или поведении между использованием CString против const CString&?

Ответы [ 2 ]

0 голосов
/ 07 января 2019

Передача по значению для нетривиального класса C ++ включает в себя вызов конструктора копирования, поэтому решение в отношении производительности зависит от того, что он делает.

Если мы говорим о MFC / ATL CString, его конструктор копирования не выполняет глубокое копирование, такое как std::string (которое действительно может быть довольно дорогостоящим для копирования, поскольку в общем случае требуется новый выделение и копирование полного содержимого), так как он реализует оптимизацию «копирование при записи» - копии данного CString фактически совместно используют резервный буфер, пока один из них не попытается изменить его, тем самым запустив фактическую копию. По этой причине копии относительно дешевы, но они все еще включают в себя некоторую атомарную целочисленную манипуляцию, которая может быть не полностью бесплатной на современных процессорах.

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

0 голосов
/ 07 января 2019

Обычно нет. Хороший компилятор и оптимизатор должен производить ту же сборку.

Это потому, что ссылки реализованы как указатели во всех основных компиляторах, и передача тривиального типа данных, такого как char*, через значение или указатель не имеет значения, поскольку на уровне сборки передача аргумента функции то же самое, sizeof(char*) == sizeof(char**).

...