Reading notes effective C + + Item 41 Understanding implicit interface and compile-time polymorphism

1. Display interface and run-time polymorphism

The world of object-oriented programming revolves around explicit interfaces and run-time polymorphism. For example, consider the following class (a meaningless Class),

1 classWidget {2  Public:3 widgets ();4 Virtual~widgets ();5 6 Virtualstd::size_t size ()Const;7 Virtual voidnormalize ();8 9 voidSwap (widget& other);//See ItemTen  One ...                                                                  A  -};

Consider the following function (also meaningless),

1 voidDoprocessing (widget&W)2 3 {4 5 if(W.size () >Ten&& W! =somenastywidget) {6 7 Widget Temp (w);8 9 temp.normalize ();Ten  One Temp.swap (w); A  - } -  the}

For W in Doprocessing, we can say this:

• Because W is declared as a widget type, W must support the Widget interface. We can search for this interface in the source code (for example, in the widget's header file) so that we know exactly what it looks like, so I call it an explicit interface (explicit interface)-an interface that can be explicitly seen in the source code.
• Because some of the member functions in the widget are virtual, W's call to these functions shows the runtime polymorphism: W specifically calls which function is determined by the dynamic type of the run-time W.

2. Implicit interface and compile-time polymorphism

The world of Templates (template) and generic programming (generic programming) has fundamentally changed. In this world, explicit interfaces and run-time polymorphism continue to exist, but they are no longer as important as before. Instead, implicit interfaces and compile-time polymorphism were moved to the foreground. To understand what this looks like, we'll convert doprocessing from a function to a function template to see what happens:

1Template<typename t>2 3 voidDoprocessing (t&W)4 5 {6 7 if(W.size () >Ten&& W! =somenastywidget) {8 9 T Temp (w);Ten  One temp.normalize (); A  - Temp.swap (w); -  the } -  -}

What can we say about W in doprocessing now?

• The interfaces that must be supported by W are determined by the action that W needs to perform in the template. For example, the type T of W must support size,normalize and swap member functions, copy Constructors (to create temp), and unequal comparisons (compared to somenastywidget). We'll soon find out that it's not very precise, but it's enough for now. Importantly, these expressions must be implicit interfaces supported by T, which must be valid for the template to be compiled.
• For function calls such as operator> and operator!= that involve w, it may involve instantiation of the template to make these calls successful. These instantiations occur at compile time. Because a function template instantiated with different template parameters causes different functions to be called, this is called " compile-time polymorphism ."

3. Differences between the display interface and the implicit interface

3.1 Features of the display interface

Even if you never use a template, you should be familiar with the difference between runtime polymorphism and compile-time polymorphism, as this is similar to the compiler's decision to call which overloaded function and the run-time decision to bind which virtual function. The difference between implicit and explicit interfaces is a new concept for templates, however, an explicit interface consists of a function signature, that is, the function name, the parameter type, the return value type, and so on. The public interface of the Widget class, for example:

1 classWidget {2  Public:3 widgets ();4 Virtual~widgets ();5 Virtualstd::size_t size ()Const;6 Virtual voidnormalize ();7 voidSwap (widget&Other );8};

Consists of a constructor, a destructor, and a function size,normalize and swap as well as a parameter type, a return value type, and the constants of these functions. (also contains the compiler-generated copy constructor and copy assignment operator-see item 5). It can also contain typedef and data members If you are bold enough to violate ITEM22 's recommendations (declare data members as private). Although this is not done in this case.

3.2 Features of the implicit interface

An implicit interface can be a lot different. It is not based on a function signature. It is made up of valid expressions. Look at the conditional expression in the start section of the doprocessing template:

1 template<typename t>2void doprocessing (t& w)3{ 4 if Ten && w! = somenastywidget) {5 ...

The implicit interface of the T (w type) appears to have the following limitations:

• It must provide a member function with a name of size and return an integer value.
• It must support the! = operator function and be able to compare objects of two t types. (Here, we assume that the type of Somenastwidget is T.) ）

Thanks to operator overloading , none of the above two restrictions need to be met. T must support a size member function, and it is worth mentioning that this function may inherit from a base class. However, this member function does not need to return an integer value. You don't even need to return a numeric type value. If you say so, it does not even need to return the value required in the operator> definition. What he needs is to return an object of type X, so you can call operator> on a type X object and an int (because 10 is an int type) object. But operator> does not need to take a parameter of type X because it can also take a parameter of type Y, as long as Y can be implicitly converted to X.

Similarly, T is not necessary to support operator!=, because operator!= with a parameter of type X and a parameter of type Y can also be accepted. The function call is valid as long as T can turn to X and the Somenastywidget type can be converted to Y.

(In other words, this analysis does not consider the possibility of overloading the operator&&, which translates the meaning of the above expression from a concatenated word into something else that is different in meaning.) ）

Most people have headaches when they first start thinking about this implicit conversion, and you don't need to take aspirin. An implicit interface is simply composed of some valid expressions. The expression itself looks complicated, but the limitations that are added to the above are generally straightforward. For example, consider the following conditional expression,

1 if Ten && w! = Somenastywidget) ...

It's hard to say what limits to function size,operator>,operator&& or operator!=, but it's easy to identify the restrictions that need to be made on the entire expression. The conditional part of the if declaration must be a Boolean expression, so whatever type is involved, and whatever the W.size () > && W! = Somenastywidget produces, it must be compatible with bool. This is part of the implicit interface that the template doprocessing imposes on the type parameter T. The interface required for the rest of the doprocessing is the call to the copy constructor, and the swap must be valid for type T.

The implicit interface imposed on the template parameter is as real as the display interface imposed on the class object, both of which are checked during the compile phase. You cannot use a class object in a way that is inconsistent with the display interface provided by a class (not compiled), nor can you try to use an object in a template, unless the object supports implicit conversions required by the template (otherwise it cannot be compiled)

4. Summary

• Both classes and templates support interfaces and polymorphism.
• For a class, the interface is displayed, centered on the function signature. Polymorphism occurs at run time, and is implemented by virtual functions.
• For template parameters, the interface is implicit, based on a valid expression. Template polymorphism is implemented through template instantiation and function overloading, which occurs at compile time.

Reading notes effective C + + Item 41 Understanding implicit interface and compile-time polymorphism