C++ Knowledge series 5
Programming language evolves always along with Compiler's evolvement
On the Cusp of the Object Model
Templates
- Template are now the foundation for generic programming ( the Standard Template Library).
- Template are used in memory allocation strategies, mutual exclusion mechanism for synchronizing thread, technique for template metaprograms.
- Class expression templates are evaluated at compile time rather than runtime, thereby providing significant performance improvements.
- This section focuses on the semantics of template support, a sort of when, why, and how of what is done with templates within a compilation system.
Template Instantiation
- First, what happens when the compiler sees the template class declaration? In terms of the actual program, nothing. That is, the static data members are not available. Nor is the nested enum or its enumerators.
- Although the actual type of the enum Status is invariant across all Point instantiations, as well as the value of its enumerators, each can be accessed only through a particular instance of the template Point class. Point< int>::enum variable = {};
- This use of the static member causes an instance associated with the float instantiation of the Point class to be generated within the program.
- Point< int>::static_variable = 99;
- If we define a pointer to a particular instance, nothing happens in the program. Why? Because a pointer to a class object is not itself a class object; the compiler does not need to know anything about the layout or members of the class. Point< float > *ptr = 0; Just same as handle
- The behavior in declaring a reference to a particular instance of a template, does result in the instantiation of a float instance of Point. Why? Because a reference cannot be an alias to "no object." The 0 is treated as an integer value that must be converted into an object of the type
- Point< float > .If there is no conversion possible, then the definition is in error and is flagged at compile time.
- Standard C++ requires that member functions be instantiated only if they are used (current implementations do not strictly follow this requirement). At compile-time.
- There are two main reasons for the use-directed instantiation rule:
- 1. Space and time efficiency. If there are a hundred member functions associated with a class, but your program uses only two for one type and five for a second type, then instantiating the additional 193 can be a significant time and space hit.
- 2. Unimplemented functionality. Not all types with which a template is instantiated support all the operators (such as i/o and the relational operators) required by the complete set of member functions. By instantiating only those member functions actually used, a template is able to support types that otherwise would generate compile-time errors.
- The definition of origin, for example, requires the invocation of the default Point constructor and destructor. Only these two functions must be instantiated.
- When defining a variable of class type, it involves calling its constructor and destructor within visible block, which is implemented by compiler.
- It's interesting to note that although operator new is implicitly a static member of the class and so may not directly access any of its non-static members, it is still dependent on the actual template parameter type because its size_t first argument is passed the class size.
- For one thing, all type-dependent checking involving the template parameters must be deferred until an actual instantiation occurs. It is different from class declaration.
- In the original cfront implementation, the template is fully parsed but not type-checked. Type-checking is applied only to each particular instantiation. So under a parsing strategy, all the lexing and parsing errors are flagged during the handling of the template declaration.
- Nonmember and member template functions are also not fully type-checked until instantiated.
Name Resolution within a Template
From:<<Inside C++ Object Model>>