Several small issues worth analyzing in C ++

Source: Internet
Author: User

Several small issues worth analyzing in C ++

I think C ++ ininner should be able to answer or identify the following three small questions. We hope that we can mine more information through questions, not just solve problems. What I like most: limited capabilities, so I hope to discuss them together and point out errors.

In addition, I have encountered a problem that I think it is necessary to record. I will write it down and talk about it. Therefore, each article may not be a single topic.

1. Let's take a look at a simple question. The following inheritance class is available:

 
 
  1. Class Person
  2. {
  3. Public:
  4. Void Walk () // "Walk" of ordinary people"
  5. {
  6. Cout <"Person: Walk I am an Ordinary People." <endl;
  7. };
  8. };
  9.  
  10. Class Student: public Person
  11. {
  12. Public:
  13. Void Walk () // student's "Walk"
  14. {
  15. Cout <"Student: Walk I am a student." <endl;
  16. };
  17. };

You are not sure whether the Walk () function is a non-virtual function. Please explain the following code:

 
 
  1. Student s; 
  2. Person* pp = &s; 
  3. pp->Walk(); 
  4.  
  5. Student* ps= &s; 
  6. ps->Walk(); 

The result is as follows:

Analysis: Walk () is a non-virtual function and is limited by static binding. Therefore, the type of pp and ps determines the called version. Here, I also want to explain the following: Understanding interface inheritance and implementation inheritance. The purpose of declaring a non-virtual function is to make the derived class inherit the function interface and a mandatory implementation. Therefore, do not redefine the inherited non-virtual function.

2. the following problem is actually about static binding and dynamic binding, but it does not seem so obvious.

 
 
  1. Class Shape
  2. {
  3. Public:
  4. Enum ShapeColor {Red, Green, Blue}; // shape color
  5.  
  6. Virtual void Draw (ShapeColor color = Red) const = 0;
  7. };
  8.  
  9. Class Circle: public Shape
  10. {
  11. Public:
  12. Virtual void Draw (ShapeColor color) const
  13. {
  14. Cout <"I am Circle: Draw .";
  15. Cout <"My color =" <color <endl;
  16. }
  17. };
  18.  
  19. Class Rectangle: public Shape
  20. {
  21. Public:
  22. Virtual void Draw (ShapeColor color = Green) const // The default parameter value is changed
  23. {
  24. Cout <"I am Rectangle: Draw .";
  25. Cout <"My color =" <color <endl;
  26. }
  27. };

I mainly want to talk about two problems.

1) when you call the following code, please explain what will happen.

 
 
  1. Circle cr; // (1) Compilation fails
  2. Cr. Draw ();
  3. Shape * ps = & cr; // (2)
  4. Ps-> Draw ();

Yes. (1) it is wrong to call an object without specifying a parameter. (2) The result is as follows: color = 0 indicates Red, which you should know.

Analysis: objects are called for static binding. You must specify the parameter value because static binding does not inherit the default parameter value from base class. Dynamic binding can inherit parameter values from base class. Note: Here I will not emphasize the concept of dynamic binding and static binding, but the following must be static binding:

 
 
  1. Circle cr;
  2. Circle * ps = & cr; // This is still static binding, and the static type is Circle *. Compilation fails.
  3. Ps-> Draw ();

2) for the second question, please explain the following call results.

 
 
  1. Shape* ps1 = new Rectangle; 
  2. ps1->Draw(); 
  3. Shape* ps2 = new Circle; 
  4. ps2->Draw(); 

The following is a gratifying result:

You mean, you have changed the default value of Draw to 1 Green in Rectangle. Why is it ineffective?

Analysis: the default value of Rectangle: Draw is GREEN, but the static type of ps2 is Shape *. Therefore, the default value of this call is from Shape class.

If you want to change the Rectangle: Draw parameter, you can call it to provide the parameter ):

 
 
  1. Shape* ps4 = new Rectangle; 
  2. ps4->Draw(Shape::Green); 
  3. Shape* ps5 = new Circle; 
  4. ps5->Draw(Shape::Green); 

This problem is to remind you that virtual functions are dynamically bound, and the default parameter value is static binding. Therefore, the default parameter value should not be redefined.

3. Why does multi-inheritance contain multiple virtual table pointers instead of one?

This question was raised by the interviewer when I saw a classmate's experience in the interview. I tried to answer it. I don't know if I am not here. Please add and correct it.

A: under multi-inheritance, the compiler implements n-1 virtual tables for a derived class. n indicates the number of base classes on the previous layer, assume that each base class has at least one virtual function. Otherwise, the compiler will not add vptr and vtbl to it. Therefore, the number of virtual tables naturally has many pointers instead of one.

In this case, I don't know why it is unreasonable. The interviewer may ask, "why do I need multiple virtual tables? Cannot a virtual table row be created ?"

This is a task done by the compiler vendor. The standards are not standardized. C ++'s father has developed such a compiler prototype. by increasing the volume of vtbl, each slot has not only one pointer, but also an offset to adjust the point of this pointer.

The disadvantage of doing so is that all virtual function pointers in vtbl contain such an offset. If you do not need to adjust this direction, you must add the offset when calling the function, the offset value is 0 at this time. In addition, the expansion of each slot volume in vtbl. These are efficiency issues.

In fact, many trunk technologies are used to adjust the point of this. Compilation is required to achieve high efficiency. In addition, the sun compiler concatenates multiple virtual tables into one, and each table contains the pointer of the next table through the offset method). In this way, a pointer is needed.

I have limited understanding. I don't know if this is the case?

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.