export / extern & templates

The problem is as follows. C ++ templates are much more functionality than macros than functions / classes. This is a clean compile-time design. It is impossible to “compile” the template so that later you can simply authenticate it to the program (as opposed to functions and classes.) Therefore, you will still need to store text in the object file, which will not give any gain.

Why is it impossible to compile a template into an object code in advance? Look at the following simple code:

template <typename T1, typename T2> void f(T1 t1) { T2 t2 = t1; } 

This is copy initialization . Depending on the types of T1 and T2 , as well as on the visibility of other types at the point of use, it can be compiled into a call to the best available conversion constructor (and type conversion T2 to the argument type of this constructor, if they do not match), conversion operator , standard conversions, numeric conversions, including loss of precision and a change in representation between a floating point and integers.

Do you think it is possible to encode all this in the object code (that is, essentially in assembly language), without knowing at the time of compilation types T1 and T2 ?

Here is a whole article from EDG, with an analysis of why the export of templates does not take off and is not worth the candle: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf . And one more: http://blogs.msmvps.com/vandooren/2008/09/24/c-keyword-of-the-day-export/ .

In more detail, the problems are the following (translated from the EDG article):

1. EDG took this feature for 1.5 years to design and 3 years to implement (comparison: for the whole Java only two years). At the same time, EDG is not “some kind of” company, they have good developers, with many years of experience developing C ++ compilers.
2. The typical structure of the C ++ compiler is not suitable for the implementation of this feature. I had to redo the design of the compiler, and most likely the same will have to be done by all other developers if export becomes an obligatory part of the standard.
3. Many of the errors that without the export of templates were not necessary to detect (for example, violation of the ODR-rule, which by the standard is only UB), with export, it actually becomes necessary to catch.
4. Formats intermediate files will have to completely change.
5. This feature does not bring so much benefit:
   • It is believed that exporting templates will no longer need to supply the source code of the libraries. This is not true. Since templates work at a level that is close to syntactic, together with the libraries, you will have to supply either template text or its direct equivalent (for example, a syntax tree), since all this information is needed during template instantiation.
   • It is believed that with the export of templates, compilation will speed up and the number of dependencies will decrease. This is not so because (due to the syntactic nature of the templates), the exported template cannot be compiled in advance. Compiling a template (at least from the syntactic tree level) will still have to be repeated, this time at the linking stage. Thus, the compiler will have to do at least the same work as without export.
   • The only really working plus of exporting templates is that macros do not leave the boundary of the translation unit. (In the case of no export, the macros defined in the template file are “visible” to everyone who uses the template.) This positive effect, however, can be achieved with the help of a stricter code organization; there are also other, easier and more effective methods for solving this problem at the level of the language standard.