Насколько я понимаю, C ++ reinterpret_cast и приведение C-указателей - это просто a compile-time functionality and that it has no performance cost at all.
Is this true?
Хорошее предположение для начала. Однако оптимизатор может быть ограничен в своих предположениях при наличии reinterpret_cast<>
или приведения указателя C. Затем, хотя само приведение не имеет связанных инструкций, результирующий код работает медленнее.
Например, если вы приведете тип int к указателю, оптимизатор, скорее всего, не будет знать, на что может указывать этот указатель. В результате, вероятно, придется предположить, что запись через этот указатель может изменить любую переменную. Это превосходит очень распространенные оптимизации, такие как хранение переменных в регистрах.
Вы правы, но подумайте об этом: reinterpret_cast означает, возможно, плохой дизайн или то, что вы делаете что-то очень низкоуровневое.
динамическое приведение вместо этого будет стоить вам чего-то, потому что оно должно искать в таблице поиска во время выполнения.
Верно. Никаких затрат, кроме выигрыша/потеря производительности при выполнении инструкций с новой шириной, которую я мог бы добавить, вызывает беспокойство только в редких случаях. Приведение между указателями на каждой платформе, о которой я когда-либо слышал, не требует никаких затрат и не влияет на производительность.
Приведения в стиле C в C++ будут сначала пытаться выполнить static_cast и выполнять reinterpret_cast только в том случае, если статическое приведение не может быть выполнено. static_cast может изменить значение указателя в случае множественного наследования (или при приведении интерфейса к конкретному типу), это вычисление смещения может потребовать дополнительной машинной инструкции. Это будет максимум 1 машинная инструкция, поэтому она очень маленькая.
reinterpret_cast
не влечет затрат во время выполнения.. однако вы должны быть осторожны, так как каждое использование reinterpret_cast
определяется реализацией. Например, переинтерпретация массива char
как массива int
может привести к тому, что целевая архитектура вызовет прерывание, поскольку разные типы могут иметь разные правила выравнивания.
Сначала исправьтесь, а потом уже беспокойтесь об эффективности.
Да, это правда. Тип приведения, который имеет стоимость времени выполнения, — dynamic_cast.