问题
I am well aware of the advantage in using static_cast rather than C-style casting for pointer types.
If the pointer types are incompatible, then:
static_castwill yield a compile-time error at a specific line within the source code- C-style casting might lead to a runtime error at a "random" point in the execution of the program
But I am unable to find any similar example for non-pointer types.
In other words, both casting methods yield the same result for non-pointer types.
Is that correct, or have I missed anything?
If yes, is static_cast used for non-pointer types only in order to maintain coding consistency?
回答1:
One advantage which the other two answers didn't mention yet is that static_cast is much easier to spot. The meaning of parentheses is notoriously overloaded in C++ and it can be difficult to spot evil (or even incorrect) casts. When I see something ending in _cast though, it's like a mental speed bump: I slow down and carefully check why the type system is being subverted.
回答2:
I'm assuming that trivial uses of references to avoid pointers won't count.
In that case: a C-style cast can be:
- a
const_cast - a
static_cast - a
static_castfollowed by aconst_cast, - a
reinterpret_cast - a
reinterpret_castfollowed by aconst_cast
with the exception that static_cast's restrictions on inaccessible base classes are lifted.
const_cast only applies to pointers and references.
reinterpret_cast only applies to pointers and references. It does include pointer-to-integer conversions and vice versa, but that still involves a pointer type.
That special exception for static_cast only applies to pointers and references.
So yes, by excluding pointers and references, you've excluded everything that C-style casts support over a static_cast.
If yes, is
static_castused for non-pointer types only in order to maintain coding consistency?
Let's go with an analogy: I wouldn't use a chainsaw to open a bag of chips. I could, but chainsaws are dangerous, so by using one, I'd introduce unnecessary risks. It's very easy to use a chainsaw wrong, and if I do use it wrong, there's no safety mechanism to prevent accidents.
回答3:
Is
static_castused for non-pointer types only in order to maintain coding consistency?
Not only that, but also to help maintain correctness and future compatibility.
It helps maintain correctness, since static_cast cannot do some casts which a C-style cast can. This helps if you make a mistake about some of the types involved, perhaps handling a pointer while being convinced it's an integer (and down several layers of templates and typedefs, that's not too difficult to imagine). So if you intend a static_cast, write one and get a compile-time error, you'll be told immediately that the types involved are not what you thought they were. With the C-style cast's "anything goes" attitude, you will not discover the mistake in time.
It also helps with future compatibility. If the types involved in the cast change later in the development, a static_cast will report an error where a C-style cast would just silently change its behaviour (to something most likely not intended).
回答4:
is static_cast used for non-pointer types only in order to maintain coding consistency?
No (well - yes, but not only).
It is also easy to find/replace. This is important in case of refactorings, bug fixing, etc.
It is a constraint on the cast type allowed: Consider an example where you have a C-style cast (which works fine) on a variable, then you change the declaration of the casted variable, to something which renders the cast invalid (for example, you change int x; to void * const x;).
The C-style cast suddenly performs another function (i.e. const_cast<...>(reinterpret_cast<...>(...)) with the same code.
If you write the initial code with a static_cast instead of a C-style cast, the compiler will let you know that static_cast in there is not actually performing a static cast.
来源：https://stackoverflow.com/questions/27525577/is-there-any-advantage-in-using-static-cast-rather-than-c-style-casting-for-non