Thread: reinterpret vs c-style cast

Originally Posted by laserlight

I see that as a Good Thing. It makes you take more time to decide if you really need the cast, and if so, if it is the right cast to use.

I fail to see that. I will reconsider it if it brings too much complexity or a big performance hit, but not if it's too long to spell. I will simply use the better alternative - C-style casts.

Originally Posted by Elysia

I fail to see that. I will reconsider it if it brings too much complexity or a big performance hit, but not if it's too long to spell.

The point is not about reconsidering, but about considering.

Originally Posted by Elysia

I will simply use the better alternative - C-style casts.

How are C-style casts the "better alternative" when they are too coarse grained, do not stand out and consequently are hard to find? Oh, and of course no C-style cast can replace dynamic_cast, if you really do need the functionality of dynamic_cast.

Originally Posted by laserlight

The point is not about reconsidering, but about considering.

The point is - I will never consider using a specific implementation or not because of the long names of casts. When I consider, I take everything else into consideration, but not the length of the casts!

How are C-style casts the "better alternative" when they are too coarse grained, do not stand out and consequently are hard to find? Oh, and of course no C-style cast can replace dynamic_cast, if you really do need the functionality of dynamic_cast.

Oh, don't get me wrong - it's great to have more safety in casts. If C++ casts were shorter, I would definitely use them.
In short - C-style casts are better cause it is less to type.

Originally Posted by Elysia

I fail to see that. I will reconsider it if it brings too much complexity or a big performance hit, but not if it's too long to spell. I will simply use the better alternative - C-style casts.

There should be no performance difference between C style casts and C++ style casts. After all, the end result should be the same - the data converted from one type to another. When it comes to reinterpret cast it's SIMPLY telling the compiler that a pointer is a different type than the compiler would normally think the pointer to be - normal usage is when you store a pointer to an object in a void * - and there is no performance to be gained or lost in converting it from void * to Object * or Object * to void *, since the pointer is still the same value.

Edit: Obviously some casts do "cost", since they actually involve instructions to convert the data - float/double to integer or other way around for example, or lengthening/shortening data (e.g. short -> int or int -> short) - although they do not need in explicit cast. Still, there is no difference between C and C++ style casts here either.

--
Mats

Originally Posted by Elysia

The point is - I will never consider using a specific implementation or not because of the long names of casts. When I consider, I take everything else into consideration, but not the length of the casts!

Read again: "Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++."

Clearly, you should not take the length of the cast operator into account when choosing to use the cast (or otherwise). The point is that, as a side effect of the name (and the fact that you have to pick one) and somewhat ugly syntactic form, you are more likely to even make a consideration instead of automatically reaching for a cast and moving on.

Originally Posted by Elysia

Oh, don't get me wrong - it's great to have more safety in casts. If C++ casts were shorter, I would definitely use them.
In short - C-style casts are better cause it is less to type.

If the need to type less really bothers you, then define your own cast function templates as I have demonstrated... but I am not sure what names would be both short and descriptive.

Not implying that C-style casts are more "efficient" than C++-style casts. I am merely pointing out that whenever I need to use casts, I would use C-style casts, even though they are "inferior" to C++-style casts, but because they are shorter.

Originally Posted by laserlight

Read again: "Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++."

No, that is not the case. I would never even consider using a C++-style cast.
I do try to avoid all types of casts, though.

If the need to type less really bothers you, then define your own cast function templates as I have demonstrated... but I am not sure what names would be both short and descriptive.

That is actually a very good advice which I will be considering for the future.

Originally Posted by Elysia

I am merely pointing out that whenever I need to use casts, I would use C-style casts, even though they are "inferior" to C++-style casts, but because they are shorter.

That sounds like a contradiction. You rightly point out that you should not make a decision about implementation "because of the long names of casts", then you now say that you choose C-style casts over C++ casts purely "because of the long names of casts", despite the advantages of C++ casts.

Would you also choose to only use one or two character variable, function and class names because they are less to type than descriptive variable, function and class names?

Originally Posted by laserlight

That sounds like a contradiction. You rightly point out that you should not make a decision about implementation "because of the long names of casts", then you now say that you choose C-style casts over C++ casts purely "because of the long names of casts", despite the advantages of C++ casts.

I fail to see the contradiction.
I avoid casts if it can be done, because both C-style and C++-style casts "interfere" with the readability of code.
That mentioned, when I need casts, I use C-style, because C++-style are too long.
But the need to use casts aren't based on whether the casts are too long to type.

Would you also choose to only use one or two character variable, function and class names because they are less to type than descriptive variable, function and class names?

I would not, but then again, I would name name something
a_function_or_variable_name_that_is_far_too_long
There is a limit to how much space we allocate for names, so to speak, and casts are no different.

Originally Posted by Elysia

There is a limit to how much space we allocate for names, so to speak, and casts are no different.

I agree, but consider your own counterexample: granted, it is exaggerated, but is not even reinterpret_cast within the normal readability limits of such names?

Originally Posted by Angus

The last time I used it, I had to use const_cast like crazy.

Unfortunately, a C-style cast is coarse-grained enough to replace const_cast.

Originally Posted by laserlight

I agree, but consider your own counterexample: granted, it is exaggerated, but is not even reinterpret_cast within the normal readability limits of such names?

For variable names, perhaps. I do prefer shorter, if possible, but for casts, I feel it is too long.

Originally Posted by Angus

Have you ever used the volatile keyword? The last time I used it, I had to use const_cast like crazy. If that was the wrong thing to do, then the right thing to do is very elusive.

What does volatile have to do with const_cast?

Originally Posted by Elysia

What does volatile have to do with const_cast?

Like const, volatile should not be possible to cast away with for example reinterpret_cast, so you use const_cast to remove (or add) volatile to a type.

--
Mats