Is reinterpret_cast any slower than a static_cast?

Question

I'm comparing two pointers of class typedef value_type which are each of type T* or char16_t.

The compiler complains that I can't compare the two because they are distinct types:

'some_type1<char16_t>::value_type*' and 'some_type2<char16_t>::value_type*' lacks a cast

Strangely, I can't static_cast<> between the two:

invalid static_cast from type 'some_type1<char16_t>::value_type*' to type 'char16_t*'

Does it make a difference whether I use reinterpret_cast<> to compare or just static_cast<> both sides to void*?

I read somewhere that reinterpret_cast<> is done at runtime but I'm not sure.

UPDATE

I was under the false impression that reinterpret_cast<> was done at runtime. With further discussion I now understand that it is purely a compile-time construct.

Curiously though, it's also been demonstrated that static_cast<> can have runtime costs where a particular object is cast into another by matching against a constructor.

For exmaple, you can cast a primitive int to a vector with static_cast<>. It would seem that this is true for all cases where static_cast<T>(e) would be valid.

Answer 1

reinterpret_cast<> is purely a compile-time cast. You're just reinterpreting what the underlying type is, completely sidestepping the type system. There is no possible runtime aspect.

static_cast<> can have a runtime cost, depending on what it is you're static_cast-ing. If you're casting a void*, or through an non-polymorphic object hierarchy, there will be no runtime cost. If you're casting through a polymorphic object hierarchy, there will be offset changes due the vtable which have to happen at runtime.

And if you're casting outside of a hierarchy, then you have to actually create a new object. Whether that looks like calling a conversion function:

struct A {
    operator B() { /* something */ }
};

A a;
static_cast<B>(a);

Or a converting constructor:

static_cast<std::vector<int>>(4);

that static_cast<> creates a whole new object - so definitely some code will need to be run to do this!

Answer 2

Even when no custom type conversion logic is involved, static_cast might have a (unnoticeable) run-time performance. This is due to the fact that in case of multiple inheritance, static_cast needs to adjust offsets to bases, and this would require run-time arithmetics. While the effect is trully miniscule, it is there. It is clear from the following code sample:

struct Mother {
  virtual ~Mother(); 
  virtual void mother();
};

struct Father { 
  virtual ~Father();
  virtual void father();
};

struct Offspring: Mother, Father {
  void mother();
  void father();
};

void foo(Offspring* offspring) {
  Mother* mother = offspring;
  mother->mother();
}

The ASM code for function foo() has following piece of line:

movq    %rax, -8(%rbp)

That is the base offset. If you remove the cast, you will see this line disappearing.

On the other hand, reinterpret_cast is trully compile-time only cast and has no effect whatsoever during program run.

Answer 3

I read somewhere that reinterpret_cast is done at runtime but I'm not sure.

No, that's wrong (from what ever source you've got that).

reinterpret_cast<> and static_cast<> are both resolved at compile time (as you see from the compiler error).

static_cast<> is slightly slower than reinterpret_cast<> because some calculations for the offsets against the base class needs to be inserted in the emitted code.

May be you were confusing that with dynamic_cast<> which is indeed done at runtime, and performing a bit slower than a reinterpret_cast<> or static_cast<>.