Does the C++ standard define a particular behaviour if you make an old C-style cast from type A to type B where type A cannot be cast to type B and vice versa?
Would there be a known visible behavior that can be assumed to be symptom of a illegal cast in runtime using this?
Only one of the four C++-style casts determines the validity of the cast at runtime, namely dynamic_cast.
A C-style cast corresponds to a combination of the other three casts (static_cast, reinterpret_cast, const_cast). The validity of those casts is determined at compile-time, or if it cannot be determined at compile-time then the cast is assumed to be valid. A C-style cast never acts like dynamic_cast.
So a C-style cast that "fails" at runtime, i.e. breaks the validity assumption, causes undefined behavior. So:
Does the C++ standard define a particular behaviour if you make an old C-style cast from type A to type B where type A cannot be cast to type B and vice versa?
No.
Would there be a known visible behavior that can be assumed to be symptom of a illegal cast in runtime using this?
No.
Compiler will catch some of them, but not all. Here is an example of a disastrous cast:
#include <iostream>
#include <string>
using namespace std;
class A {
public:
A(std::string s, int x) : m_s(s), m_x(x) {}
void print() { cout << "A::print(): str = " << m_s << ", x = " << m_x << endl; }
private:
std::string m_s;
int m_x;
};
class B {
public:
B(int x) : m_x(x) {}
void print() { m_x++; cout << "B::print(): x = " << m_x << endl; }
private:
int m_x;
};
int main(int argc, char **argv) {
A *a = new A("abc", 1);
a->print();
B *b = (B*)a;
b->print();
a->print();
return 0;
}
Result on gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609:
A::print(): str = abc, x = 1
B::print(): x = 24828977
A::print(): str = bc, x = 1
Yes, we called B's methods on A's data, which means that our C-style cast worked as reinterpret_cast. reinterpret_cast just takes a memory region and allows you to treat is as something different. No seatbelts here.
On the other hand, if you try to compile something like this
A a;
B b;
a = (A)b;
return 0;
it will result in static_cast and compile-time error. So C-style casting result depends on context.
This is NIGHTMARE when dealing with templates and auto.
To avoid this problem, use static_cast (for compile-time checks) and dynamic_cast (for runtime checks) or reinterpret_cast (for pointers and POD), clearly stating your intent.
Related
Is the following code safe :
#include <iostream>
#include <cstdint>
struct A{
int i = 0;
virtual int foo() {return i;}
};
struct B : A{
int foo() override {return i+2;}
};
using handle_t = std::uintptr_t;
handle_t get(B& a){
return reinterpret_cast<handle_t>(&a);
}
void use(handle_t h){
auto p= reinterpret_cast<A*>(h); //
std::cout << p->foo() << "\n";
}
int main(int argc, char *argv[])
{
B a;
auto h = get(a);
use(h);
return 0;
}
CppReference's page says one can :
reinterpret_cast from B* to std::uintptr_t
reinterpret_cast from std::uintptr_t to B* (because it's the same type back and forth)
reinterpret_cast from B* to A*
So, is it safe to merge the last two ?
I don't know what "safe" means, but the behavior of a program that uses this code is undefined. You can convert a pointer into an integer type that's large enough to hold the value, and you can convert that value back into a pointer with the same type as the original. The code in the question doesn't do that: it converts the value into a pointer with a different type from the original.
In that particular case the code is safe. That's because the safety of upcasting. This is always allowed for public inheritance, without an explicit type cast.
In short you're just force something could be consider as implicit.
The passage of B type's address with a uintptr_t is useless also but allowed because "the same type".
Edit
About uintptr_t.
Integer type capable of holding a value converted from a void pointer and then be converted back to that type with a value that compares equal to the original pointer.
Note "compares equal to the original pointer".
is it legal to cast between pointers on classes that have common ancestor? Does the compiler notice such hierarchy and makes sure its safe (call 1) ?
Or does the user have to go through the hierarchy manually for it to be always safe (call 2) ?
say we have
class A{};
class B:A{};
class C:A
{
public:
int SomeFunc(){return 3;}
};
int _tmain(int argc, _TCHAR* argv[])
{
B* b = (B*)((A*)new C()); // this is done manually, i believe it is safe
((C*)b)->SomeFunc(); // is this safe? this is the cast in question
return ((C*)((A*)b))->SomeFunc(); // this is done manually, i believe it is safe
}
edit: Made this code compilable and runnable
edit2: Added more comments
B* b = (B*)((A*)new C()); // this is done manually, i believe it is safe
This is not safe.
Casts of the form (T) expr are, roughly speaking, converted into either static_cast or reinterpret_cast. [expr.cast]/4:
The conversions performed by
a const_cast (5.2.11),
a static_cast (5.2.9),
a static_cast followed by a const_cast,
a reinterpret_cast (5.2.10), or
a reinterpret_cast followed by a const_cast,
can be performed using the cast notation of explicit type conversion.
The same semantic restrictions and behaviors apply […] If a
conversion can be interpreted in more than one of the ways listed
above, the interpretation that appears first in the list is used, even
if a cast resulting from that interpretation is ill-formed.
You can ignore const_cast here as no qualification conversions are done in your code.
static_cast suffices in both casts, the first one, (A*), and the second one, (B*).
The first one is just fine. Upcasting is never an issue.
The second one induces undefined behavior. [expr.static.cast]/11:
A prvalue of type “pointer to cv1 B,” where B is a class type,
can be converted to a prvalue of type “pointer to cv2 D”, where
D is a class derived (Clause 10) from B, if a valid standard
conversion from “pointer to D” to “pointer to B” exists (4.10),
cv2 is the same cv-qualification as, or greater cv-qualification than, cv1, and B is neither a virtual base class of D nor a base
class of a virtual base class of D. […] If the prvalue of type
“pointer to cv1 B” points to a B that is actually a subobject of an
object of type D, the resulting pointer points to the enclosing
object of type D. Otherwise, the result of the cast is undefined.
Note also that just because the static_cast triggers UB that doesn't mean it isn't selected (and replaced by reinterpret_cast).
The second and third casts base on the first one (which causes undefined behavior), thus talking about their validity is pointless.
Unless you really really know what your doing, don't do that.
The casts are legal, but using them on anything but the correct class results in undefined behaviour, any use of b without further casts results in UB, which might work, do nothing or start WWIII.
The casts simply tells the compiler that is should consider the variable to be of another type (unless it is multiple inheritance), but as soon as the cast variable is used it must actual be legal to use it in the way the code does, using B's function table is no good if the object is a C or vice versa. As this is undefined behaviour the compiler might emit whatever code it feels is right.
Example
class AA { };
class BB { };
class CC : public AA, public BB { };
int main () {
CC cc; // address is 0x22aa6f
BB* bb = &cc; // bb now is 0x22aa6f
cout << &cc << "," << bb << "\n";
return EXIT_SUCCESS;
}
Gives
0x22aa6f,0x22aa6f
Example with multiple inheritance
class AX{ int a = 1; };
class BX{ int b = 2; };
class CX:AX,BX {
public:
int c = 3;
int SomeFunc(){cout << "SomeFunc " << c << " "; return c;}
};
int cast() {
CX* c;
BX* b = (BX*)((AX*)(c = new CX())); // this is done manually, i believe it is safe
cout << "c=" << c << ", b=" << b << ", cx=" << ((CX*)b) << ", ca=" << ((CX*)((AX*)b)) << endl;
((CX*)b)->SomeFunc(); // is this safe? this is the cast in question
return ((CX*)((AX*)b))->SomeFunc(); // this is done manually, i believe it is safe
}
int main () {
return cast();
}
output
c=0x60003ac70, b=0x60003ac70, cx=0x60003ac6c, ca=0x60003ac70
SomeFunc 2 SomeFunc 3
c is the real address of the new
b is the cast to AX first which is c then to BX (which doesn't make any sense for AX) but b is just set to the same address as c
cx is b reinterpreted as CX, multi-inheritance kicks in and really change the address as if b was the 2nd class in the inheritance.
ca is the correct reinterpretation of b through AX and then CX.
The 2 calls to SomeFunc works despite the wrong address
the function call is found through the current type which is CX due to the last cast.
the wrong addresses are passed as this pointer
because this is not used it works, so I had to add some use.
now we have entered undefined behaviour due to the cast (BX*)((AX*)c which makes the cast (CX*)b do the wrong thing.
To check if it is safe you need to use dynamic_cast.
int main() {
A* AP = new C();
C* CP = dynamic_cast<C*>(A);
if (CP != nullptr)
CP->SomeFunc();
return EXIT_SUCCESS;
}
To check whether a cast is meaningful or not just use dynamic_cast. dynamic_cast will cast properly if cast is safe OR returns NULL (in case of pointers, for references it throws bad_cast exception ) if its not able to cast to target type.
For your question just think about whether this cast is meaningful. You are casting B class to C where these classes have no knowledge of each other. So, surely this cast would fail.
You are doing:-
B* b = (B*)(new C());
This would fail(means won't even compile ) if given to dynamic_cast since classes involved are not polymorphic. Even if you make class B polymorphic cast would fail. Leave further casting.
One more thing you can cross cast using dynamic_cast safely assuming classes are polymorphic and cast is safe. For e.g:-
class A;
Class B;
Class C : public A, public B
A *a = new C;
You can cast this to sibling:-
B *b = dynamic_cast<B*> (a);
Your casts are both legal and correct but very dangerous. You should use reinterpret_cast<> to tag them in your code.
You can always cast any address of any type A to any other address of any type B and get your first address back. This is essentially what you've done:
A *pa = &some_a;
B *pb = reinterpret_cast<B *>(pa);
pa = reinterpret_cast<A *>(pb);
and then dereference pa. This example works but it is so easy to make a mistake...
I was confused about why can't compare pointers to member using binary operator<
class Point3d{
protected:
//..
public:
float x;
static list<Point3d*> *freeList;
public:
float y;
static const int chunkSize = 250;
public:
float z;
};
and a template:
template< class class_type, class data_type1, class data_type2 >
char* access_order(data_type1 class_type:: *mem1, data_type2 class_type:: *mem2)
{
return
mem1 < mem2 ?
"member 1 accurs first":
"member 2 accurs first";
}
when I called the access_order like below:
access_order(&Point3d::z, &Point3d::y);
the g++ reported:
"invalid operands of types ‘float Point3d::*’ and ‘float Point3d::*’ to binary ‘operator<’"
Is there a way compare pointer to member, I mean the unequal comparison, and how?
You can compare the addresses of the members of an object:
A a;
if (std::less<void*>()(&a.a, &a.b))
std::cout << "a precedes b\n";
else
std::cout << "a follows b\n";
One of the best option - make a raw copy via std::memcpy, calculate hash and then use it for comparison (thanks #HolyBlackCat for comments). The function below calculates the hash for passed pointer-to-member (tested on modern C++ 17 compilers VS, GCC. CLang).
#include <cstring>
#include <string_view>
#include <functional>
template <typename TObject, typename TMember>
size_t HashMemberPtr(TMember TObject::* memberPtr)
{
char buf[sizeof memberPtr];
std::memcpy(&buf, &memberPtr, sizeof memberPtr);
return std::hash<std::string_view>{}(std::string_view(buf, sizeof buf));
}
Unfortunately it's not compatible with std::hash<> as last requires only one template argument.
How to use:
struct CPoint3D
{
float x;
float y;
float z;
};
int main()
{
const size_t xHash = HashMemberPtr(&CPoint3D::x);
assert(xHash == HashMemberPtr(&CPoint3D::x));
assert(xHash != HashMemberPtr(&CPoint3D::y));
assert(xHash != HashMemberPtr(&CPoint3D::z));
return 0;
}
For the same reason you can't compare pointers in general. The only
comparisons for order that are supported is if two data pointers point
into the same array. Otherwise, the results of the comparison are
unspecified; a compiler is not required to make the operators "work" in
any reasonable way. (Ensuring a total order here would require extra
computation on some architectures.) Since there's no case you can get
specified results for a pointer to member, the standard doesn't allow
them as arguments to the operators.
If you need total ordering, std::less et al. is guaranteed to provide
it. Including, if I understand the standard correctly, member pointers.
(Although providing a total ordering for pointer to member functions
would probably be very expensive.) Even then, however, this ordering
may be arbitrary; it would certainly not be required to reflect any
ordering in memory.
If the Point3d overloads < then deference them and do the compare,
return
*mem1 < *mem2 ?
"member 1 accurs first":
"member 2 accurs first";
or change the signature
char* access_order(data_type1 class_type:: &mem1, data_type2 class_type:: &mem2)
char* access_order(data_type1 class_type:: mem1, data_type2 class_type:: mem2)
Did you want to do the compare on the actual memory address?
Pointers to members do not point to some memory themselves. They are just labels. The only thing you can do with them is to convert them to reference to pointee value of the given object with operator .* or ->* or store in another pointer to member variable.
struct A
{
int a;
float b;
};
A a;
int A::* p2m = &A::a;
int A::* p2m2 = p2m;
int & realPointer = a.*p2m;
Note, that you only can compare pointers of the same type, so you can't compare pointer to A::a (int A::*) with pointer to A::b (float A::*)
Pointer comparison seem to tempting everyone but they always lead to a non-portable or undefined behavior.
The easiest answer is that you should never do this. There is no computational problem that cannot be solved with classical approaches.
Don't get me wrong, I am aware that asking wrong questions might get interesting thoughts, or a build better understanding on how a language or even CPU works.
For static_cast, Is it true that, unless there exist a built-in type conversion function, you cannot use static_cast to perform conversion. But you can do a reinterpret_cast for a type, considering the return type is valid.
int main()
{
WORD word;
HWND hwnd = static_cast<HWND>(word); // error
HWND hwnd = reinterpret_cast<HWND>(word); // ok, considering a valid handle is returned.
}
Do the explicit type conversions done with static_cast require a conversion function unlike reinterpret_cast?
reinterpret_cast just allows you to convert completely unrelated types. It just treats the chunk of memory as another type. So it is very unsafe to use it, since it just doesn't give you any compile or runtime errors but just causes (usually) crash
static_cast provides compile time check of validity of an cast. If an type cannot be treated as another type then static_cast gives you an compile time error when attempting an cast.
It does implicit conversions between types (such as int to float, or pointer to void*), and it can also call explicit conversion functions (or implicit ones).
So you can say that it can do the implicit casts for which there is an implicit conversion inbuilt function present. It is usually considered as replacement for c-style casting if that is the confusion.
The C++ casts make most sense when casting pointers and references.
Concrete examples
void foo (Base & b) {
if (b .is_a_Foo ())
static_cast <Foo &> (b) .bar ();
else
b .do_default_bar ();
dynamic_cast <Baz &> (b) .something (); // throws if invalid conversion
}
char data [4];
* reinterpret_cast <float *> (data) = 1.23;
The Windows API is a horrible hack from top to bottom -- in your example, reinterpret_cast is faithful to the original intent (and highlights it for the world to admire) and it basically means "throw away the type system and use the raw bits: trust me".
Basically static_cast allocates memory for compatible class size of destination type and fills it with what is possible, but without any checking that new object is complete. Let me give you an example:
class A {
public:
int a;
};
class B : public A {
public:
int c;
int b;
};
int main()
{
A *a = new A;
a->a = 5;
B *b = new B;
b->a = 6;
b->b = 7;
b->c = 8;
B* bb = static_cast<B*>(a);
A* aa = static_cast<A*>(b);
cout << bb->a << endl; // 5
cout << bb->b << endl; // scrap value from memory
// member b was not initialized, because it was not found in A
cout << aa->a << endl; // 6
return 0;
}
In your example static cast is invalid, because hwnd is void * and word is unsigned short. For c++ casts any type can be considered as a class;
reinterpret_cast works always. It is just a binary copy
From the book Exceptional C++ Solution to ch. 44 I've learned that they are situations when none of the new cast styles would work properly. I always thought that they (those 4 new casts) cover every possible situation and there is no need for "old" style cast anymore, but it appears to be not true. So my question is:
Are those new casts cover all possible situations so there is no need to ever use c-style cast or:
There are situation in which only the old cast works properly?
Thanks.
That's appropriate fragment from this book:
"
class A { public: virtual ~A(); /*...*/ };
A::~A() { }
class B : private virtual A { /*...*/ };
class C : public A { /*...*/ };
class D : public B, public C { /*...*/ };
A a1; B b1; C c1; D d1;
const A a2;
const A& ra1 = a1;
const A& ra2 = a2;
char c;
void f()
{
A* pa; B* pb; C* pc;
pa = (A*)&ra1;
pa = (A*)&a2;<<----------This is the cast I'm interested in
//This cannot be expressed as a new-style cast. The closest candidate is const_cast,
//but because a2 is a const object, the results of using the pointer are undefined.
//Not my words those are words of Herb Sutter. (whose style of writing irritates me to bits)
pb = (B*)&c1;
pc = (C*)&d1;
}
"
EDITED
Chapter 44 from Exceptional C++:
"Item 44. Casts
Difficulty: 6
How well do you know C++'s casts? Using them well can greatly improve the reliability of your code.
The new-style casts in standard C++ offer more power and safety than the old-style (C-style) casts. How well do you know them? The rest of this problem uses the following classes and global variables:
class A { public: virtual ~A(); /*...*/ };
A::~A() { }
class B : private virtual A { /*...*/ };
class C : public A { /*...*/ };
class D : public B, public C { /*...*/ };
A a1; B b1; C c1; D d1;
const A a2;
const A& ra1 = a1;
const A& ra2 = a2;
char c;
This Item presents four questions.
Which of the following new-style casts are not equivalent to a C-style cast?
const_cast
dynamic_cast
reinterpret_cast
static_cast
For each of the following C-style casts, write the equivalent new-style cast. Which are incorrect if not written as a new-style cast?
void f()
{
A* pa; B* pb; C* pc;
pa = (A*)&ra1;
pa = (A*)&a2;
pb = (B*)&c1;
pc = (C*)&d1;
}
Critique each of the following C++ casts for style and correctness.
void g()
{
unsigned char* puc = static_cast<unsigned char*>(&c);
signed char* psc = static_cast<signed char*>(&c);
void* pv = static_cast<void*>(&b1);
B* pb1 = static_cast<B*>(pv);
B* pb2 = static_cast<B*>(&b1);
A* pa1 = const_cast<A*>(&ra1);
A* pa2 = const_cast<A*>(&ra2);
B* pb3 = dynamic_cast<B*>(&c1);
A* pa3 = dynamic_cast<A*>(&b1);
B* pb4 = static_cast<B*>(&d1);
D* pd = static_cast<D*>(pb4);
pa1 = dynamic_cast<A*>(pb2);
pa1 = dynamic_cast<A*>(pb4);
C* pc1 = dynamic_cast<C*>(pb4);
C& rc1 = dynamic_cast<C&>(*pb2);
}
Why is it typically unuseful to const_cast from non-const to const? Demonstrate a valid example in which it can be useful to const_cast from non-const to const."
Solution to chapter 44
Solution
Let's answer the questions one by one.
Which of the following new-style casts are not equivalent to a C-style cast?
Only dynamic_cast is not equivalent to a C-style cast. All other new-style casts have old-style equivalents.
Guideline
Prefer new-style casts.
For each of the following C-style casts, write the equivalent new-style cast. Which are incorrect if not written as a new-style cast?
void f()
{
A* pa; B* pb; C* pc;
pa = (A*)&ra1;
Use const_cast instead:
pa = const_cast<A*>(&ra1);
pa = (A*)&a2;
This cannot be expressed as a new-style cast. The closest candidate is const_cast, but because a2 is a const object, the results of using the pointer are undefined.
pb = (B*)&c1;
Use reinterpret_cast instead:
pb = reinterpret_cast<B*>(&c1);
pc = (C*)&d1;
The above cast is wrong in C. In C++, no cast is required:
pc = &d1;
}
Critique each of the following C++ casts for style and correctness.
First, a general note: All of the following dynamic_casts would be errors if the classes involved did not have virtual functions. Fortunately, A does provide a virtual function, making all the dynamic_casts legal.
void g()
{
unsigned char* puc = static_cast<unsigned char*>(&c);
signed char* psc = static_cast<signed char*>(&c);
Error: We must use reinterpret_cast for both cases. This might surprise you at first, but the reason is that char, signed char, and unsigned char are three distinct types. Even though there are implicit conversions between them, they are unrelated, so pointers to them are unrelated.
void* pv = static_cast<void*> (&b1);
B* pb1 = static_cast<B*>(pv);
These are both fine, but the first is unnecessary, because there is already an implicit conversion from a data pointer to a void*.
B* pb2 = static_cast<B*> (&b1);
This is fine, but unnecessary, since the argument is already a B*.
A* pa1 = const_cast<A*>(&ra1);
This is legal, but casting away const (or volatile) is usually indicative of poor style. Most of the cases in which you legitimately would want to remove the const-ness of a pointer or reference are related to class members and covered by the mutable keyword. See Item 43 for further discussion of const-correctness.
Guideline
Avoid casting away const. Use mutable instead.
A* pa2 = const_cast<A*>(&ra2);
Error: This will produce undefined behavior if the pointer is used to write on the object, because a2 really is a const object. To see why this is a legitimate problem, consider that a compiler is allowed to see that a2 is created as a const object and use that information to store it in read-only memory as an optimization. Casting away const on such an object is obviously dangerous.
Guideline
Avoid casting away const.
B* pb3 = dynamic_cast<B*>(&c1);
Potential error (if you try to use pb3): Because c1 IS-NOT-A B (because C is not publicly derived from B—in fact, it is not derived from B at all), this will set pb3 to null. The only legal cast would be a reinterpret_cast, and using that is almost always evil.
A* pa3 = dynamic_cast<A*>(&b1);
Probable error: Because b1 IS-NOT-AN A (because B is not publicly derived from A; its derivation is private), this is illegal unless g() is a friend of B.
B* pb4 = static_cast<B*>(&d1);
This is fine, but unnecessary because derived-to-public-base pointer conversions can be done implicitly.
D* pd = static_cast<D*>(pb4);
This is fine, which may surprise you if you expected this to require a dynamic_cast. The reason is that downcasts can be static when the target is known, but beware: You are telling the compiler that you know for a fact that what is being pointed to really is of that type. If you are wrong, then the cast cannot inform you of the problem (as could dynamic_cast, which would return a null pointer if the cast failed) and, at best, you will get spurious run-time errors and/or program crashes.
Guideline
Avoid downcasts.
pa1 = dynamic_cast<A*>(pb2);
pa1 = dynamic_cast<A*>(pb4);
These two look very similar. Both attempt to use dynamic_cast to convert a B* into an A*. However, the first is an error, while the second is not.
Here's the reason: As noted above, you cannot use dynamic_cast to cast a pointer to what really is a B object (and here pb2 points to the object b1) into an A object, because B inherits privately, not publicly, from A. However, the second cast succeeds because pb4 points to the object d1, and D does have A as an indirect public base class (through C), and dynamic_cast is able to cast across the inheritance hierarchy using the path B* D* C* A*.
C* pc1 = dynamic_cast<C*>(pb4);
This, too, is fine for the same reason as the last: dynamic_cast can navigate the inheritance hierarchy and perform cross-casts, so this is legal and will succeed.
C& rc1 = dynamic_cast<C&>(*pb2);
}
Finally, an "exceptional" error: Because *pb2 isn't really a C, dynamic_cast will throw a bad_cast exception to signal failure. Why? Well, dynamic_cast can and does return null if a pointer cast fails, but since there's no such thing as a null reference, it can't return a null reference if a reference cast fails. There's no way to signal such a failure to the client code besides throwing an exception, so that's what the standard bad_cast exception class is for.
Why is it normally unuseful to const_cast from non-const to const?
The first three questions included no examples of using const_cast to add const, for example, to convert a pointer to non-const to a pointer to const. After all, explicitly adding const is usually redundant—for example, it's already legal to assign a pointer to non-const to a pointer to const. Normally, we only need const_cast to do the reverse.
And the last part of the question: Demonstrate a valid example where it can be useful to const_cast from non-const to const.
There is at least one case in which you could usefully const_cast from non-const to const—to call a specific overloaded function or a specific version of a template. For example:
void f( T& );
void f( const T& );
template<class T> void g( T& t )
{
f( t ); // calls f(T&)
f( const_cast<const T&>(t) ); // calls f(const T&)
}
Of course, in the case of choosing a specific version of a template, it's usually just easier to name it explicitly instead of forcing the right deduction. For example, to call the right version of a templated function h(), writing "h( t )" is preferable to writing "h( const_cast(t) )".
In that situation, const_cast will have exactly the same effect as a C cast. Both will give a non-const pointer to a constant object, and in both cases trying to modify the object will give undefined behaviour.
Any conversion can be made using some combination of C++ casts, but there are some cases where a C cast can make a conversion that no single C++ cast can. For example, reinterpret_cast can't remove const or volatile qualifications, and const_cast can't convert between two unrelated pointer types; but a C cast can do both at once:
class A;
class B;
A const* a = 0;
B* b;
b = reinterpret_cast<B*>(a); // fail: can't remove const
b = const_cast<B*>(a); // fail: can't convert between pointer types
b = reinterpret_cast<B*>(const_cast<A*>(a)); // OK
b = (B*)a; // OK
I would still prefer to see the the two casts in this case, at the cost of extra typing; it makes it clear that something freaky is going down, and uses a syntax that can be searched for. In my opinion, C casts should never be used for anything.
In C++, the old-style casts are defined in terms of the new-style casts.
5.4:
4 Any type conversion not mentioned
below and not explicitly defined by
the user (12.3) is ill-formed.
5 The conversions performed by
— a const_cast (5.2.11),
— a static_cast (5.2.9),
— a static_cast followed by a
const_cast, — a reinterpret_cast
(5.2.10), or — a reinterpret_cast
followed by a const_cast, can be
performed using the cast notation of
explicit type conversion.
The example you provided is covered quite cleanly by the first bullet. Your comment at the end of the example is only half right. You can read the result, but you can not write to it. This is the same whether you use const_cast or not. The underlying object does not lose its const-ness just because you cast it away.
A few clauses later, a few situations in which a C-style cast behaves differently from a regular static_cast are listed. But they have to do with casting along inheritances in which the base class is inaccessible. The virtual in your example suggests that maybe there was some inheritance in the book's actual code; perhaps that is what he was trying to get at, and you misunderstood?
For completeness:
7 In addition to those conversions, the
following static_cast and
reinterpret_cast operations
(optionally followed by a const_cast
operation) may be performed using the
cast notation of explicit type
conversion, even if the base class
type is not accessible:
— a pointer to
an object of derived class type or an
lvalue of derived class type may be
explicitly converted to a pointer or
reference to an unambiguous base class
type, respectively;
— a pointer to
member of derived class type may be
explicitly converted to a pointer to
member of an unambiguous non-virtual
base class type;
— a pointer to an
object of non-virtual base class type,
an lvalue of non-virtual base class
type, or a pointer to member of non-virtual base class type may be explicitly converted to a pointer, a reference, or a
pointer to member of a derived class type, respectively.
As an example of what that last clause is talking about, here is something only possible with a C-style cast.
class Base { };
class Derived : Base { };
Derived d;
Base* pb;
pb = static_cast<Base*>(&d); //inaccessible base
pb = (Base*)(&d); //just fine
However, I am finding it hard to imagine a situation where this would not be a bad idea. For practical purposes, just assume C-style casts don't exist.
The closest candidate is const_cast, but because a2 is a const object, the results of using the pointer are undefined.
Just to be clear, the C-style cast (A*)&a2 also yields undefined behavior. So const_cast is not "the closest candidate", it is the equivalent.
All that seems to prove is that everything has an edge case. I've never come across that situation in the real world.
By the way, did you have a question?