Do constant and reinterpret cast happen at compile time?

Question

I have read that static_cast happens at compile time and dynamic_cast happens at run time thus are slower than static_cast. A dynamic_cast can either return a null ptr (when using with a pointer) or otherwise throw a bad cast exception. My question is what about reinterpret_cast and const_cast do they happen at compile time or run-time ? I would think that interpret cast happens at run-time since it behaves like dynamic_cast indicating if the cast was successful. Am i correct ? What about const_cast is that compile time ?

Answer 1

The dynamic cast is the only that needs to be "calculated" in run-time. All other casts are calculated in compile-time.

• The machine code for a static_cast is a fixed function based on the type you are casting FROM and TO.
• The machine code for a const_cast is in fact nothing more than allow a const value to be passed as no-const or vice-versa. So it can be resolved in compile-time
• For reinterpret_cast, the machine code can be resolved in compile-time as well. Once it's nothing more than "look to a pointer that is pointing to a type A with the eyes of who is looking for the type B".
• The dynamic_cast needs to resolve virtual tables and adjust the correct addresses of virtual methods based on the type FROM and TO. That's why it's more complex!

Answer 2

• const_cast

  • used to add or remove const-ness - is entirely compile time - it doesn't affect the actual code generated for run-time execution - only whether the compiler stops with an error when it sees the code attempting to write to a const value.

  • used to add or remove volatility - happens at compile time, but the compiler may then generate typically more and/or slower code when volatile is added, or less/faster code when volatile's removed; these code changes affect runtime performance (and correctness, if volatility's needed)

• reinterpret_cast changes the compiler's perspective on data and may result in different code being executed at runtime; while there's no runtime cost involved with the cast itself, the cast-to type might need more or less code (and processing cycles) in the surrounding context of use than the cast-from type needed (if it even supported those semantics of usage)

• static_cast also picks cast-to-type appropriate code to insert at compile time - much as a reinterpret_cast - but the data itself may undergo an extra conversion (static_cast<T>(x) is equivalent to T temp(x);)... the conversion clearly can add code and runtime overhead

• dynamic_cast: the compiler considers its knowledge of the actual types involved.

  • If the code context in which the dynamic_cast is performed only knows about the cast-from object via a pointer or reference from some other code, and is unable to determine the real runtime type of the variable, it's obliged to use Run-Time Type Information (RTTI) to see whether/how the runtime type relates to the cast-to type.

  • If the actual cast-from type is known at compile time, the compiler can substitute the equivalent of a static_cast between the two pointer or reference types. Using its knowledge of the actual types it can determine whether the pointer/reference needs to be adjusted (e.g. adding or subtracting some number of bytes corresponding to the offset of one of the classes in the other) or ends up being effectively a reinterpret_cast of the same address.

Answer 3

A very detailed specification exists here that answers your question:

http://en.cppreference.com/w/cpp/language/reinterpret_cast

Effectively, reinterpret_cast<> leaves no run-time footprint.

const_cast is compile time as well, no code needs to be generated.