Я думаю, что стоит викифицировать этот вопрос.
FWIW, я соглашаюсь. Я обычно пытаюсь найти более "универсальный" термин для своих базовых классов. Таким образом, если бы я имею "Клиентский" класс и должен представить новый базовый класс для него, я пошел бы с "Контактом" или чем-то, а не "CustomerBase".
Не должно быть никакой разницы, если вы сравните int ()
с эквивалентной функциональностью static_cast
.
Использование VC2008:
double d = 10.5;
013A13EE fld qword ptr [__real@4025000000000000 (13A5840h)]
013A13F4 fstp qword ptr [d]
int x = int(d);
013A13F7 fld qword ptr [d]
013A13FA call @ILT+215(__ftol2_sse) (13A10DCh)
013A13FF mov dword ptr [x],eax
int y = static_cast<int>(d);
013A1402 fld qword ptr [d]
013A1405 call @ILT+215(__ftol2_sse) (13A10DCh)
013A140A mov dword ptr [y],eax
Очевидно, это на 100% то же самое!
Никакой разницы.
Когда дело доходит до таких базовых конструкций, как одинарное приведение, если две конструкции имеют одинаковое семантическое значение, их производительность будет полностью идентична, и сгенерированный машинный код для этих конструкций будет одинаковым.
Они такие же, поскольку они разрешаются во время самой компиляции, и нет дополнительных затрат времени выполнения. Даже если бы была какая-то разница, я бы не стал особо беспокоиться об этих крошечных (даже не микро) оптимизациях.
When you choice makes little difference to the code, I'd pick the one which looks more familiar to later programmers. Making code easier to understand by others is always worth considering. In this case, I'd stick to int(…)
for that reason.
Я считаю, что фактический результат определяется реализацией. Вы должны проверить это в своей версии компилятора. Но я считаю, что это даст тот же результат в большинстве современных компиляторов. А в C ++ вы не должны использовать C-cast, вместо этого используйте C ++ cast - это позволит вам находить ошибки во время компиляции.
Взгляните на сборку, используя каждый метод. Если он отличается, используйте профилировщик.