[This is a clear article about C ++ dynamic_cast] dynamic_cast in C ++

(Based on: Writing "C ++" for many years"CodeThis is the first time I think of dynamic_cast. It has never been used. I 've probably learned it online. I found this good one.Article. In addition, I cannot figure out where to use dynamic_cast .)

----------------- The following is a reference -----------------------------

Reference address (it seems that the link is invalid ):

Http://skywalkerj.spaces.live.com/blog/cns! 49c467f1b758d6fc! 146. Entry? Sa = 1, 20850098

Reprinted address:

Http://blog.csdn.net/shj348794/article/details/4302584

What is the use of dynamic_cast? In fact, dynamic_cast is one of the only two usages in ansi c ++ related to rtti (Run time type identification. The class inheritance of C ++ makes it difficult to find out which class the object you are using, especially when the inheritance tree is deep and complex. For example, when youProgramTo get a cwnd * pointer, your intention is that if it actually points to a dind object, it will call its domodal method. At this time, you need dynamic_cast:   Cwnd * pwin = mygetwin (); Cdialog * pdlg = NULL: If (pdlg = dynamic_cast <cdialog *> (pwin )) Pdlg-> domodal ();   Can I use a simple forced type conversion or static_cast? It does not work. If pwin actually points to a view object, your program will call domodal () for the view object. In MFC, you may just get an assert, in some cases, you may get a segment fault. According to the Objective C ++, undefined usage may cause this program to send a cut-off letter to your friends in love. If it is a multi-threaded program, it is normal that you spend a whole day playing log crazy.   When dynamic_cast is used, if the actual object is not cdialog, a null pointer will be passed back. Even if you forget to write if then, you can quickly use the debugger to locate the error. The bug of NULL pointer is probably the happiest of all bugs.   Dynamic_cast uses the rtti mechanism provided by the compiler. The Compiler puts the type information of a class somewhere in the C ++ runtime system, often at the end of vtbl, in this way, the vptr is obtained from the class pointer and the vtbl is obtained from the vptr to check whether the type information matches.   The usage of dynamic_cast is rare because it is actually a "bad" usage, which destroys some basic principles of O-O to some extent. Since a base class type is defined to hide the differences of the derived classes and provide a unified interface, why do you want to restore the differences from the outside? As mentioned in more than one typical C ++ discussion, dynamic_cast should not be left a living space in a well-designed class inheritance system.   However, there is always a distance between the Bible and the actual life. Sometimes the architecture is not so perfect, but a bunch of objects are managed using an array of base class pointers. You must use a specific method of a derived class, the class library does not provide you with such a path, so you have to do it yourself and deconstruct it. As shown in the preceding example, it is hard to say that this situation will not be met in practice.   Some people may say that I will handle this problem by myself. I will add a type data member to the base class and then create a GetType () method, each derived class object is assigned different values during construction. when calling the object, let's make a judgment. Isn't that OK? You can also do this, but first, your implementation efficiency is much lower than the rtti Implementation of the compiler. You need to increase the space overhead of one word for each object, the compiler adds a little space for a class, because the compiler can use the existing vptr and vtbl, but you cannot control the C ++ Runtime Library. Next, let's move back to Step 1. Why do we need to design C ++? You can use pure C Programs to implement class encapsulation, inheritance, and polymorphism mechanisms. It's nothing more than using a bunch of function pointers! How did early C ++ programs compile? A pre-processor is used to translate the code into C and then compile the Code with the C compiler. C ++ is used, not to write less code, but to make the program structure clearer. Therefore, as long as the compiler provides this function, do not bother yourself.   The most interesting thing about dynamic_cast is that the mainstream C ++ compilers generally provide the compilation option to turn rtti off to meet the requirements of some stingy C programmers, this can reduce some space overhead. If you use this compilation option, and your program uses dynamic_cast, aha, the wonderful segment fault will immediately hit you.   In many Mail-list statements, we can see that some people complain about the program crash caused by dynamic_cast. Some of the G ++-used reviewers also understand that they have added the-fno-rtti option, old people who answer questions often use foolish to describe such behavior. People who use visual c ++ are even worse. The Cl compiler in vc6 is set to disable rtti by default. You must select it on the Project Settings page by yourself, or manually add the "/GR" option. It is estimated that some people have suffered this pain point by trying to port the openh323 class library in windows.   The innocent programmer is like this. He thinks there is a problem with what is defined in the ansi c ++ standard? However, he encountered an enthusiastic master build and turned off the rtti option to optimize the performance. I think this is a classic question to measure the configuration management level of a software development team.