Удар по производительности из-за приведения стилей C++?

Если приведение в стиле C++ может быть концептуально заменено приведением в стиле C, накладных расходов не будет. Если это невозможно, как в случае с dynamic_cast, для которого нет эквивалента C, вы должны так или иначе оплатить стоимость.

В качестве примера следующий код:

int x;
float f = 123.456;

x = (int) f;
x = static_cast<int>(f);

генерирует идентичный код для обоих приведений с VC++ - код:

00401041   fld         dword ptr [ebp-8]
00401044   call        __ftol (0040110c)
00401049   mov         dword ptr [ebp-4],eax

Единственное приведение C++, которое может генерировать, — это dynamic_cast при приведении к ссылке. Чтобы избежать этого, выполните приведение к указателю, который вернет 0 в случае неудачного приведения.

Единственным, требующим каких-либо дополнительных затрат во время выполнения, является dynamic_cast, у которого есть возможности, которые в любом случае нельзя воспроизвести напрямую с помощью приведения в стиле C. Так что у вас нет проблем.

Самый простой способ убедиться в этом — поручить вашему компилятору сгенерировать вывод на ассемблере и изучить сгенерированный им код. Например, в любом разумно реализованном компиляторе reinterpret_cast вообще исчезнет, ​​потому что это просто означает «идти вслепую и притворяться, что данные относятся к этому типу».

Почему должен быть хит производительности? Они выполняют точно те же функции, что и приведения C. Единственное отличие состоит в том, что они обнаруживают больше ошибок во время компиляции и их легче искать в исходном коде.

static_cast<float>(3) полностью эквивалентен (float)3 и будет генерировать точно такой же код.

Учитывая float f = 42.0f, reinterpret_cast<int*>(&f) точно эквивалентно (int*)&f и будет генерировать точно такой же код.

И так далее. Единственное отличие — это dynamic_cast, которое, да, может генерировать исключение. Но это потому, что он делает вещи, которые не могут делать актеры в стиле C. Так что не используйте dynamic_cast, если вам не нужна его функциональность.

Обычно можно с уверенностью предположить, что составители компиляторов умны. Имея два разных выражения, которые имеют одинаковую семантику в соответствии со стандартом, обычно можно с уверенностью предположить, что они будут одинаково реализованы в компиляторе.

К сожалению. Второй пример должен быть, конечно, reinterpret_cast, а не dynamic_cast. Исправлено сейчас.

Хорошо, просто чтобы было абсолютно ясно, вот что говорит стандарт C++:

§5.4.5:

Преобразования, выполненные

• a const_cast (5.2.11)
• a static_cast (5.2.9)
• static_cast, за которым следует const_cast
• a reinterpret_cast (5.2.10), or
• reinterpret_cast, за которым следует const_cast.

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

Таким образом, что угодно, так как приведение в стиле C реализовано в терминах приведения C++, приведение в стиле C должно быть медленнее. (Конечно, это не так, потому что компилятор в любом случае генерирует один и тот же код, но это более правдоподобно, чем более медленное приведение типов в стиле C++.)

Существует четыре приведения в стиле C++:

• const_cast
• static_cast
• reinterpret_cast
• dynamic_cast

Как уже упоминалось, первые три являются операциями времени компиляции. За их использование не взимается штраф во время выполнения. Это сообщения компилятору о том, что данные, которые были объявлены одним способом, должны быть доступны другим способом. «Я сказал, что это int*, но позвольте мне получить к нему доступ, как если бы это был char*, указывающий на sizeof(int) chars» или «Я сказал, что эти данные доступны только для чтения, и теперь мне нужно передать их функции, которая не будет их изменять. , но не принимает параметр как константную ссылку."

Помимо повреждения данных из-за приведения к неправильному типу и перебора данных (всегда возможно с приведениями в стиле C), наиболее распространенная проблема во время выполнения с этими приведениями заключается в том, что данные, которые на самом деле объявлены const, не могут быть преобразованы в неконстантные. Приведение чего-то объявленного const к неконстантному, а затем его изменение не определено. Не определено означает, что вам даже не гарантируется получение сбой.

dynamic_cast — это конструкция времени выполнения, и она должна иметь стоимость времени выполнения.

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

При использовании dynamic_cast во время выполнения выполняется несколько проверок, чтобы вы не сделали глупостей (подробнее см. список рассылки GCC), стоимость одного dynamic_cast зависит от того, сколько классов затронуто, какие классы затронуты и т. д.
Если вы действительно уверены в безопасности приведения, вы все равно можете используйте reinterpret_cast.

Хотя я согласен с утверждением, что «единственный, кто имеет какие-либо дополнительные затраты во время выполнения, это dynamic_cast», имейте в виду, что могут быть различия в зависимости от компилятора.

Я видел несколько ошибок, зарегистрированных в моем текущем компиляторе, где генерация кода или оптимизация немного отличались в зависимости от того, используете ли вы приведение static_cast в стиле C или в стиле C++.

Так что если переживаете, проверьте разборку на хотспотах. В противном случае просто избегайте динамических приведений, когда они вам не нужны. (Если вы отключите RTTI, вы все равно не сможете использовать dynamic_cast.)

Каноническая истина — это сборка, поэтому попробуйте обе и посмотрите, получится ли у вас другая логика.

Если вы получите точно такую ​​же сборку, то разницы никакой и быть не может. Единственное место, где вам действительно нужно придерживаться старых приведений C, — это подпрограммы и библиотеки чистого C, где нет смысла вводить зависимость от C++ только для приведения типов.

Одна вещь, о которой следует знать, это то, что приведения типов происходят повсюду в куске кода приличного размера. За всю свою карьеру я никогда не искал «все приведения» в части логики — вы, как правило, ищете приведения к определенному ТИПУ, например «A», а поиск по «(A)» обычно столь же эффективен, как и что-то вроде "static_cast‹A›". Используйте новые приведения типов для таких вещей, как проверка типов и тому подобное, не потому, что они облегчают поиск, который вы никогда не сделаете.