... and they are more likely to do what you intend. ;-)
–
MackeJun 27 '11 at 11:51

3

And they are a lot more to type, giving you one more reason to just get your types correct without casts needed.
–
Michael KohneJun 27 '11 at 12:05

2

And they are ugly as a feature, making obvious where in the code there might be points of improvement or special cases that might require documentation. - edit: wow I just discovered I answered this question too! XD
–
KlaimJun 27 '11 at 12:26

What is happening here is that the programmer is asking the compiler to do whatever it can to make the cast.

The difference is important because using static_cast will only ask for a base type that is "safe" to convert to, where reinterpret_cast will convert to anything, possibly by just mapping the wanted memory layout over the memory of the given object.

So, as the "filter" is not the same, using specific cast is more clear and safe than using the C cast, if you rely on the compiler (or runtime impl. if you use dynamic_cast) to tell you where you did something wrong, by avoidng C cast and reinterepret_cast.

Now that this is more clear, there is another thing : static_cast, reinterpret_cast, const_cast and dynamic_cast are easier to search for.

And the ultimate point : they are ugly. That's wanted. Potentially buggy code, code smells, obvious "tricks" that might generate bugs, are easier to track when it's associated with ugly look. Bad code should be ugly.

That's "by design". And that allow the developer to know where he could have done things better (by totally avoiding casts, if not really needed) and where it's fine but it's "documented" in the code by "marking" it as ugly.

A secondary reason for introducing the
new-style cast was that C-style casts
are very hard to spot in a program.
For example, you can't conveniently
search for casts using an ordinary
editor or word processor. This
near-invisibility of C-style casts is
especially unfortunate because they
are so potentially damaging. An ugly
operation should have an ugly
syntactic form. That observation was
part of the reason for choosing the
syntax for the new-style casts. A
further reason was for the new-style
casts to match the template notation,
so that programmers can write their
own casts, especially run-time checked
casts.

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++.

I added a quote from the C++ initial creator that point the "ugly by design" thing. It seems that the ugliness of the syntax was part of the design from the start (but I guess they figured that while working on fixing the initial problems).
–
KlaimMar 1 '11 at 10:39

Dis-applying a const must always use a const_cast. For obvious reasons. Sadly, my rule about dis-applying a const causing the keyboard to reach up and break the programmer's finger was not approved.

Any of the bit-manipulation-style shenanigans that programmers get up to when getting down to the metal should use reinterpret_cast. It's really the kind of cast that C doesn't have: pretend this integer's bits are actually a float's bits. This avoids unpleasantness like (int)(*(int*)(&floatVar)).

If you type the words "dynamic_cast", stop and re-evaluate your polymorphic class hierarchy and design. Continue re-evaluating your class hierarchy's design until you can delete those words.

Don't bother with static_cast.

The reasoning behind #4 is simply that it doesn't matter. The circumstances that don't fit into the other rules are either obvious or really low-level. A well-understood conversion of simple types like int-to-float should not need special syntax. And if you're down in the deep, ugly guts of something, well, you're down in the deep, ugly guts of something. There's no need to draw attention to the fact that "here there be dragons," since the teeth, claws, and fire pretty much gave it away already.

dynamic_cast is a perfectly valid tool. Rarely useful, I'll admit, but it's far from the Satan of things like global variables. However, primarily, I downvoted you because you didn't answer the question, which was about the use or not of C-style casts.
–
DeadMGJun 27 '11 at 18:25

@DeadMG: I did talk about C-style casts. The whole last paragraph justifies C-style casts in favor of static_cast.
–
Nicol BolasJun 27 '11 at 21:38

It really depends on which language I'm working with, since you know what they say: In Rome speak Roman.
So if I'm programming in C, I try to use the C features to the max, but if I'm programming at C++ I go ahead and use C++ features to the max, even if some people don't like that approach because they say it makes the code "less portable", I say that I don't care, I'm in C++ and programming in C++, and I need a fully C++ compatible compiler to compile code, otherwise I would be working with something different in the first place.

static_cast etc were invented because of problems with the C style casts when used in templates. If you're writing a template, or if you're code may later be converted to a template, it's a good idea to use C++-style casts. The reason is because the C++-style casts better express intent, so they will give the expected results in cases where C-style casts will do the wrong thing (given particular types as template parameters).

Other than that, I say use C++-style casts if you have a specific issue that needs them - dynamic_cast is the most common, but even that's probably not an every day thing.

Anything else, and a C style cast may be a bit less clutter and help readability, or maybe not depending on how familiar the reader is with that cast style these days. It's not really important in my view, mostly a personal preference thing, though don't be surprised if some people don't like the C style.

Final note - if you need so many casts that this is a big deal, you're probably doing something else wrong. There are exceptions to that in some cases, but most high level code shouldn't need many (if any) casts.