Four tricky basics in C ++ template. The complete guide

Here we will talk about the concept of tricky. I don't want to list them one by one, but I want to give them a try.

The first is typename, which is used to tell the compiler that the next thing to follow is a type rather than anything else. Assume that you have a map class. You need two template parameters, key and value.

Template <class K, Class V> class Map <br/>{< br/> Public: <br/> struct mappair <br/>{< br/> K key; <br/> V value; <br/>}; <br/> mappair getpair (); <br/> };

With this class, we need to implement the getpair method here. We write down the implementation of this function step by step:

Template <class K, Class V> Map <K, V >:: mappair Map <K, V >:: getpair () but when compiling,

The GCC compiler (I am using gcc 3.4.5 bound to codeblock, which may be older) tells us "error: Expected constructor, destructor, or type conversion before "map" | ||=== build finished: 1 errors, 0 warnings ==|"

The vs2005 compiler tells us "error c2143: syntax error: Missing '; 'before' Map <K, V >:: getpair'" and "error c4430: missing type specifier-int assumed. note: C ++ does not support default-Int"

Here we can see that the vs compiler is quite reliable and can guide you on this typename keyword, but GCC is a bit strange. The solution here is to write this function:

Template <class K, Class V> typename Map <K, V >:: mappair Map <K, V >:: getpair ()

Here, typename indicates that: mappair indicates that mappair is a type rather than a variable in Map <K, V>. In this way, variables are often seen in STL. I just don't pay special attention to it, for example, the following example:

Typedef typename _ traits: int_type; <br/> typedef typename _ traits: pos_type; <br/> typedef typename _ traits: off_type;

The above is a definition in STL istream, where no typename may not be compiled. What's more, statements like typename T: subtype * PTR; If typename is not added and compiled, it is very scary to multiply the variable subtype parsed into T by PTR.

 

There is another problem that we thought was okay. This is the question mentioned in this article.

Let's look at an example:

# Include <iostream> <br/> void exit () <br/> {<br/> STD: cout <"global exit" <STD: Endl; <br/>}< br/> template <typename T> class base <br/>{< br/> Public: <br/> void exit () <br/>{< br/> STD: cout <"base exit" <STD: Endl; <br/>}< br/> }; <br/> template <typename T> class derived: public base <t> <br/>{< br/> Public: <br/> void Foo () <br/>{< br/> exit (); <br/>}< br/>}; <br/> int main (INT argc, _ tchar * argv []) <br/>{< br/> derived <int> D; <br/> D. foo (); <br/> system ("pause"); <br/> return 0; <br/>}< br/>

The feature here is that the exit () function is called in the foo function of the derived class. The problem is that there are two functions, one is the global exit function, and the other is the member function in the parent class base. Which function is called now? We have tried both GCC and vs compilers.

Vs compiler seems to have made great progress and has been improving these template problems. The output here is "base exit ". As we wish. However, "global exit" is output in GCC (GCC 3.4.5 ". Again, one potential problem you can think of is that if you write a module that is public on Windows Mobile and Symbian, even if it can run on Windows Mobile, however, the behavior on Symbian may be different ..

Therefore, using this-> exit (); or base: exit (); is a secure solution.

This chapter involves more than this. For example, the usage of. template is also mentioned. However, if it was just a few minutes ago, there would be no special meaning. For the next analysis.