error: invalid static_cast from type 'xxx*' to type 'yyy*'
7868 ワード
文書ディレクトリ error: invalid static_cast from type 'xxx*' to type 'yyy*' [What good is static_cast?][1]
error: invalid static_cast from type ‘xxx*’ to type ‘yyy*’
通常、static_castは、まったく異なる2つのタイプであるため、異なるポインタタイプ間の変換には適用されない.自分が何をしているかを自分で知っている場合は、通常、異なるポインタタイプの変換にreinterpret_を使用します.cast
C++標準は以下の通りである.
次はBjarne Stroustrupから抜粋します
What good is static_cast?
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?:
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:
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++.
error: invalid static_cast from type ‘xxx*’ to type ‘yyy*’
通常、static_castは、まったく異なる2つのタイプであるため、異なるポインタタイプ間の変換には適用されない.自分が何をしているかを自分で知っている場合は、通常、異なるポインタタイプの変換にreinterpret_を使用します.cast
C++標準は以下の通りである.
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から抜粋します
What good is static_cast?
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++.