What is the most concise but accurate way to describe what a virtual function is in C ++?

They are asked to describe which virtual function appears to be one of the most common interview questions evaluating basic C ++ knowledge. However, after several years of C ++ programming, I still have an uncomfortable feeling that I really don't understand how best to determine what they are.

If I consult wikipedia, I see that the definition of a virtual function is:

"In object-oriented programming, a virtual function or virtual method is a function or method whose behavior can be redefined within an inheriting class by a function with the same signature"

This definition seems simple and elegant, not specific to C ++. But for me, this does not look like the concept of a virtual function in C ++, since, of course, a non-virtual function can also be redefined inside the inheriting class by a function with the same signature.

If I am asked to describe that a virtual function is informal, I’m saying something about pointers, such as "this is a method that when you call it with a pointer to a base class, the version of it defined in the derived class is called instead, if the pointer is actually points to an instance of a derived class. " This doesn't seem like a very elegant description of the concept. I know that people say that this is how “polymorphism” is achieved in C ++ (polymorphism, as I understand it, roughly speaking, is the whole idea of ​​organizing objects in a hierarchy), but I don’t know what a fascinating way to understand or explain a mechanism than going through an example with pointers.

I guess I'm confused by the fact that the description of virtual functions "pointer" is something fundamental for their definition or just something random for their implementation in C ++.

+6
c ++ function polymorphism oop virtual
source share
10 answers

I always thought that this quote reflects the essence of virtual functions:

A virtual function is a way of defining a family of related actions that can be configured by entities that really need to perform these behaviors.

If you ignore all C ++ types of virtual functions - how virtual functions allow dynamic_cast to work for objects of class type, how they are processed almost exclusively when accessed through a pointer, how virtual destructors are completely different from virtual non-destructors, etc. - I think that the above statement underlies all virtual functions.

The main reason I like this statement is because it describes virtual functions in a way that separates them from programming. You can explain virtual functions to a non-technical person using this definition by providing some specific analogues. For example, the idea of ​​“turning on the light” can be considered as a virtual function, because the actual mechanics of what happens when you turn on the light depends entirely on the specific light that you use (incandescent lamp?), But the conceptual idea is the same in each case. Of course, this is not an ideal analogy, but I think that it fits well enough.

More generally, IMHO, if you are ever asked to describe something informally, try to distance yourself as much as possible from the specific programming language you are using and, if at all possible, from computers in general. Try to come up with the most general setting that applies the concept, and then describe it at that level. Again, I teach CS introductory courses, and therefore I have a bit of bias towards this domain, so I have no idea how applicable this is in setting up an interview .:-)

+6
source share

since, of course, a non-virtual function can also be redefined inside the inheriting class by a function with the same signature.

No, this is not true. In this case, the function is only redefined, not redefined.

+2
source share

Your unofficial definition is a good summary of what the virtual pointer does. It looks like you also want to describe how this works, but since the C ++ standard is not specified, any description of how will be specific to a particular implementation, and not to the C ++ language in general.

The C ++ standard deals with behavior and says almost nothing about implementation. There's even an as-if rule that allows any alternative implementation to provide the same visible behavior.

+1
source share

" I think I'm confused by whether the description of" virtual functions "is a pointer" something fundamental for their definition or just something random for their implementation in C ++. "

This is no coincidence. The concept of virtual functions only works for pointers or references.


Virtual functions are needed when a method of a derived class that has the same signature and has a base class is redefined for different functions.

 class Polygon { public: virtual float area() { std::cout << "\n No formula in general \n" ; } virtual ~Polygon(); }; class Square { public: float area() { std::cout << "\n Side*Side \n" ; } ~Square(); } Polygon* obj = new Square ; obj -> area() ; // Ok, Square::area() is called. Square obj1; Polygon& temp = obj1 ; // Ok, Square::area() is called Square obj2; Polygon temp1 = obj2 ; // Polygon::area() is called because of object slicing. 
+1
source share

The difference is how the compiler decides which implementation is “bound” to the method call when compiling the source code. For virtual futums, the chosen implementation is based on a specific type of the actual object itself, and not on the type of variable. This means that when you put an object in a base class or interface, the implementation that will be executed is still the implementation defined on the derived class, which is actually the object.

In puesdo code

  // for a virtual function public class Animal { public virtual void Move() { Print "An animal Moved." } } pubic class Dog: Animal { public void Move() { Print "A Dog Moved." } } Animal x = new Dog(); x.Move() // this will print "A Dog Moved." 

For a non-virtual function, the selected implementation will be based on the type of the variable, which means that when you drop the object into the base class (i.e. change the type of the variable), a specific implementation of the method in the base class will select the compiler and it will be executed, and not an implementation in a derived class ...

 // for a non-virtual function public class Animal { public void Move() { Print "An animal Moved." } } pubic class Dog: Animal { public void Move() { Print "A Dog Moved." } } Animal x = new Dog(); x.Move() // this will print "An animal Moved." 
+1
source share

Let's say that Beta is a subclass of Alpha, and it can either create a new method scope () or add a virtual one.

It makes no difference if you are talking with a beta pointer. But if you are talking to Alpha *, which points to a Beta object, you will get the Alpha method. If you do not declare the function virtual.

There is a function dispatch table in the Beta subclass, which is a copy of the Alpha table, but with additional beta methods at the end. If Beta simply overrides the method, it will go into the Beta section of the distribution table, so links to Alpha * will not see the new method. But, if the new method is virtual, it will go into the Alpha section of the Beta class table.

Suppose you have a subclass of Circle from Shape. And let it be said that you have a pointer to a Shape object, x, which happens to be an instance of Circle. x-> area () will see only the part of the function table related to Shape. If Circle serves as a virtual area, it appears in the "Form" section of the table. If Circle simply redefines the region, then the region method will be placed in the circular part of the table, and Shape * x will not see the new function.

In C ++, there is only one function table for each class. This is a bit confusing for people who are used to writing in a scripting language, where each object has its own distribution table. Thus, scripting languages ​​are extremely inefficient. Imagine that all the space is occupied for each object.

0
source share

If the interview is about your knowledge in C ++, I believe that sin does not refer to a pointer.

You can simply say that "virtual functions are a mechanism that allows an object to express this class behavior, even if it accessed it through a pointer to the base class."

More than that (if you are thinking of "pure virtual functions"), it is also a mechanism to force an entire class hierarchy to provide a specific method without defining the default implementation of the method in the base class.

0
source share

Idea

The main difference between a virtual and a non-virtual method is the binding of the method name to the implementation of the actual method. A virtual method is bound at runtime based on a type. A non-virtual function is bound at compile time.

A little earlier:

A virtual method is one that can be overridden in a derived type.
Thus, when a virtual method is invoked (via a pointer or reference), runtime binding is used to select the version of the method that is defined in the derived version itself; based on the type of actual object (referenced or referenced).

C ++ notes

Note. The method is virtual, even if you do not use the virtual keyword, if the ancestor declares a method with the same signature as the virtual one.

0
source share

A virtual function is where the caller decides the behavior. A non-virtual function is a function in which the caller defines the behavior.

Is this concise enough?

0
source share

Although pointers are necessary for using virtual functions in C ++, I would say that pointers are random for the idea, and explanations that are independent of pointers are clearer. I think that templatetypedef and Charles_Bretana got into the main idea.

The reason pointers seem to creep into describing virtual functions is because only pointers and references can have different runtime types and compilation types. A variable whose type is class Foo must contain Foo at run time, so it does not matter if a virtual function is used. But a variable whose type is class Foo * can point to any subclass of Foo, so this is a situation where virtual functions and non-virtual functions behave differently.

0
source share

All Articles