通常来说, static_cast 不适用于不同指针类型之间的转换, 因为它们是完全不同的两个类型. 如果
3.9.1 Fundamental types [basic.fundamental] 1 Objects declared as characters char shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (basic.types); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.
下面这个是摘自 Bjarne Stroustrup
Casts are generally best avoided. With the exception of dynamic_cast, their use implies the possibility of a type error or the truncation of a numeric value. Even an innocent-looking cast can become a serious problem if, during development or maintenance, one of the types involved is changed. For example, what does this mean?:
x = (T)y;
We don’t know. It depends on the type T and the types of x and y. T could be the name of a class, a typedef, or maybe a template parameter. Maybe x and y are scalar variables and (T) represents a value conversion. Maybe x is of a class derived from y’s class and (T) is a downcast. Maybe x and y are unrelated pointer types. Because the C-style cast (T) can be used to express many logically different operations, the compiler has only the barest chance to catch misuses. For the same reason, a programmer may not know exactly what a cast does. This is sometimes considered an advantage by novice programmers and is a source of subtle errors when the novice guessed wrong.
The “new-style casts” were introduced to give programmers a chance to state their intentions more clearly and for the compiler to catch more errors. For example:
int a = 7; double* p1 = (double*) &a; // ok (but a is not a double) double* p2 = static_cast<double*>(&a); // error double* p2 = reinterpret_cast<double*>(&a); // ok: I really mean it const int c = 7; int* q1 = &c; // error int* q2 = (int*)&c; // ok (but *q2=2; is still invalid code and may fail) int* q3 = static_cast<int*>(&c); // error: static_cast doesn't cast away const int* q4 = const_cast<int*>(&c); // I really mean it
The idea is that conversions allowed by static_cast are somewhat less likely to lead to errors than those that require reinterpret_cast. In principle, it is possible to use the result of a static_cast without casting it back to its original type, whereas you should always cast the result of a reinterpret_cast back to its original type before using it to ensure portability.
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++.