> That gives me: "error: invalid cast from type 'char' to type 'char'" on both > gcc 4.4.4 and MSVC++ 2008.
> My real problem was
> unsigned char a[] = { 7, 3, 14 }; > int b;
> b = reinterpret_cast<int>(a[0]);
> which gave the same error (but with respective types).
> It works with the plain C-style cast.
> Now the questions.
> 1. Is reinterpret_cast broken?
No. The situation above needs static_cast.
> 2. Am I doing something wrong?
Yes. The chapter "5.2.10 Reinterpret cast" in the C++ standard does say "... Conversions that can be performed explicitly using reinterpret_cast are listed below. No other conversion can be performed explicitly using reinterpret_cast." And then it goes on listing the conversions. Your "identity" integral type to integral type conversion is not in the list, thus is it marked as error by the compilers.
> 3. What's the difference anyway between reinterpret_cast and plain C-style cast?
C style cast is defined as application of series of C++ style casts, the first from the list that is usable will be used to do the conversion:
- a const_cast - a static_cast - a static_cast followed by a const_cast - a reinterpret_cast - a reinterpret_cast followed by a const_cast
In your case, it uses the second conversion in the list above.
> That gives me: "error: invalid cast from type 'char' to type 'char'" on both gcc 4.4.4 and MSVC++ 2008.
> My real problem was
> unsigned char a[] = { 7, 3, 14 }; > int b;
> b = reinterpret_cast<int>(a[0]);
> which gave the same error (but with respective types).
> It works with the plain C-style cast.
> Now the questions.
> 1. Is reinterpret_cast broken?
I don't believe so.
> 2. Am I doing something wrong?
Yes, you need no cast there at all, and in cases where you do, try static_cast (e.g. you should get warned if you do a[0] = b, and if you're sure that you're OK with this assignment, then static_cast should do it).
I understand reinterpret_cast like this: it's only useful for low- level bit-twiddling. Types are passed to it must match in size, and I am forcing the compiler to let me "reinterpret" ;-) underlying memory in a different way.
I, for example, remove plain C casts from old C++ code occasionally, and by automatism, I used reinterpret_cast. Eventually it dawned on me that it's actually seldom appropriate, at least for the kinds of casts I am seeing. I would guess other people got into the same wrong habit.
> 3. What's the difference anyway between reinterpret_cast and plain C-style cast?
E.g. reinterpret_cast preserves const qualifier (with pointers and references, not the case in your snippet). Also all C++ casts stand out like a sore thumb, as opposed to a sneaky little bastard from C! :-)
DeMarcus wrote: > Consider this: > That gives me: "error: invalid cast from type 'char' to type 'char'" on > both gcc 4.4.4 and MSVC++ 2008.
> My real problem was
> unsigned char a[] = { 7, 3, 14 }; > int b;
> b = reinterpret_cast<int>(a[0]);
> which gave the same error (but with respective types).
> It works with the plain C-style cast.
> Now the questions.
> 1. Is reinterpret_cast broken? > 2. Am I doing something wrong? > 3. What's the difference anyway between reinterpret_cast and plain > C-style cast?
reinterpret_cast is used to convert between *pointers* of unrelated types, and whether or not it works is implementation specific. It can cause undefined behavior unless you really know what it will do "under the hood", which is why one should try to avoid it if possible.
What you need for the above code is static_cast, which is similar to a C-style cast except that the compiler will issue a diagnostic if you really need reinterpret_cast or C-style cast.
With C-style cast, all caution is thrown to the wind, and you are on your own WRT to error-checking.
> That gives me: "error: invalid cast from type 'char' to type 'char'" on > both gcc 4.4.4 and MSVC++ 2008.
This is correct and intended.
> My real problem was
> unsigned char a[] = { 7, 3, 14 }; > int b;
> b = reinterpret_cast<int>(a[0]);
> which gave the same error (but with respective types).
Why don't you use static_cast or rely on implicit conversion here?
> It works with the plain C-style cast.
Because C-style cast is a hammer for everything and C++ didn't want to make this design error when introducing the three different type conversion operators static_cast, const_cast, and reinterpret_cast. The C-cast allows several conversions that can be realized by combining these three operators mentioned above.
The reinterpret_cast conversion operator is specifically intended to perform a reinterpretation of a bit pattern of type T to another type type U and does not involve the call of any conversion functions or converting constructors nor is it intended to break cv-correctness.
> Now the questions.
> 1. Is reinterpret_cast broken?
No, this design is intended.
> 2. Am I doing something wrong?
I would say yes. Use static_cast or no cast at all.
> 3. What's the difference anyway between reinterpret_cast and plain > C-style cast?
Robert Hairgrove wrote: > reinterpret_cast is used to convert between *pointers* of unrelated types,
I regularly use reinterpret_cast to convert a pointer to an integer and back. Also, I believe reinterpret_cast can well be used with a reference type as target.
> and whether or not it works is implementation specific. It can cause > undefined behavior unless you really know what it will do "under the > hood", which is why one should try to avoid it if possible.
Yes, what it does is mostly implementation defined, though I believe there was this "shouldn't surprise anyone familiar with the target achitecture".
Anyway, to the OP: How about using the right datatype from the start? The point is that many conversions bear the danger of any information loss and they all cause unnecessary overhead. Yes, this doesn't answer your question about reinterpret_cast, but saying "use static_cast" should be considered the second option in "fixing" the code.
