My understanding is that C++ reinterpret_cast and C pointer cast is a just a compile-time functionality and that it has no performance cost at all.
Is this true?
A:
Yes, this is true. Casting type which has runtime cost is dynamic_cast.
Alex Farber
2010-08-26 12:59:52
`static_cast` can have runtime cost as well; though it's usually just a single pointer adjustment, or code to covert one type to another (such as an `int` into a `float`)
Billy ONeal
2010-08-26 13:04:30
Won't `static_cast` also call user-defined conversions? The runtime cost on those is unbounded.
Ben Voigt
2010-08-26 13:13:29
Right, static_cast has runtime cost in the case of type (not pointer) conversion. My point is that dynamic_cast is the only cast type which has additional runtime cost, relatively to C casting.
Alex Farber
2010-08-26 13:26:57
+2
A:
That's right. No cost other than any gain/loss in performance for performing instructions at the new width, which I might add, is only a concern in rare cases. Casting between pointers on every platform I've ever heard of has zero cost, and no performance change whatsoever.
Matt Joiner
2010-08-26 12:59:55
A:
You're right, but think about it: reinterpret_cast means maybe a bad design or that you're doing something very low level.
dynamic-cast instead it will cost you something, because it has to look in a lookup table at runtime.
vulkanino
2010-08-26 13:04:01
`dynamic_cast` is more akin to `static_cast` with runtime checking rather than `reinterpret_cast`. You cannot cast polymorphic types with `reinterpreT_cast`.
Billy ONeal
2010-08-26 13:07:51
A:
reinterpret_cast does not incur runtime cost.. however you have to be careful, as every use of reinterpret_cast is implementation defined. For example, it is possible reinterpreting a char array as an int array could cause the target architecture to throw an interrupt, because different types may have different alignment rules.
Get correct first, then worry about efficiency.
Billy ONeal
2010-08-26 13:06:40
+14
A:
It's a good assumption to start with. However, the optimizer may be restricted in what it can assume in the presence of a reinterpret_cast. Then, even though the cast itself has no associated instructions, the resulting code is slower.
For instance, if you cast an int to a pointer, the optimizer likely will have no idea what that pointer could be pointing to. As a result, it probably has to assume that a write through that pointer can change any variable. That beats very common optimizations such as storing variables in registers.
MSalters
2010-08-26 13:09:56
I don't think "usually not" was the response you intended for the question "is this true?"
Rob Kennedy
2010-08-26 16:11:54
thank you very much for this answer. Maybe in that case one may hint GCC with the register keyword (!?).
poulejapon
2010-08-27 10:08:08
Highly unlikely. On older implementations, the optimizer did little more than assign variables to registers. Using `register` would turn off that functionality. Nowadays, register assignment algorithms are much, much better. For instance, they can reuse a register for multiple variables, and assign a variable to a register for only part of its lifetime. As a result, the `register` keyword for a variable is effectively ignored.
MSalters
2010-08-30 09:18:43
+1
A:
C style casts in C++ will attempt a static_cast first and only perform a reinterpret_cast if a static cast cannot be performed. A static_cast may change the value of the pointer in the case of multiple inheritance (or when casting an interface to a concrete type), this offset calculation may involve an extra machine instruction. This will at most be 1 machine instruction so really very small.
doron
2010-08-26 14:17:27