| 1 | | === TBD === |
| | 1 | == Scenario when using Explicit Template Instantiation == |
| | 2 | |
| | 3 | (Compliments of Kian-Tat Lim) |
| | 4 | |
| | 5 | If explicit instantiation can be used (i.e. if all template parameters |
| | 6 | that will be used by the application are known ahead of time), then |
| | 7 | the following is the best method: |
| | 8 | |
| | 9 | 1) Put only the interface (template definition) in a .h file in a |
| | 10 | public include directory. |
| | 11 | |
| | 12 | 2) Put only the implementation in a .cc file in a private |
| | 13 | implementation or source directory. This does not actually need to be |
| | 14 | compiled as such (although doing so does no harm, as it generates no |
| | 15 | code). |
| | 16 | |
| | 17 | 3) Add an additional .cc file that includes the .h file, the |
| | 18 | implementation .cc file from #2, and then explicitly instantiates the |
| | 19 | templates with the known parameters using "template class C<T>;" |
| | 20 | statements. |
| | 21 | |
| | 22 | 4) Compile everything, including application code, with |
| | 23 | -fno-implicit-templates. |
| | 24 | |
| | 25 | 5) Make sure the explicit instantiations resulting from compiling the |
| | 26 | .cc file in #3 are included in the appropriate library for application |
| | 27 | code to link against. |
| | 28 | |
| | 29 | This method isolates the application from changes to the template |
| | 30 | implementation, requiring only a relink against the new library rather |
| | 31 | than a recompile against the new template implementation code. |
| | 32 | |
| | 33 | |
| | 34 | |
| | 35 | == User Friendly Templates: A Scenario == |
