Darren New <dne### [at] sanrrcom> wrote:
> The whole "export template" bit I don't understand. I have to believe 
> that either there are restrictions on what a template can do and still 
> be able to be an export template, or there are bits in the object file 
> which are essentially getting recompiled at compile-time.

  AFAIK there are no restrictions on what an export template function
can contain.

  The basic implementation of export templates, from the point of view
of the compiler, is that the template *source* code gets written to the
object file (either as raw source code or some kind of pre-parsed code
or whatever; I don't know how eg. gcc does it in practice). When the
linker sees that it needs a specific instance for a certain template
function, it calls the compiler and tells it "I need an instance of
this template function with these types", the compiler compiles the
function for those types, and then the linker uses the generated code.

  As you might imagine this is far from trivial to implement, which is
the reason why so few compilers support this.

  In theory you could distribute template code as "precompiled" object
files, without the original source. However, I assume that with most
implementations of export templates, creating a decompiler for those
object files is probably fairly trivial (because, after all, the object
file has to have the original source code in one form or another inside
it for the whole export template mechanism to be possible).

  Btw, there's an additional advantage in export templates besides the
smaller simpler header files and object files, and it's one which cannot
be used with compilers which do not support export templates and it can
have very practical uses: Export template code can use functions and
types which are local to that compilation unit. This can be used to
increase modularity (by hiding implementation details).

-- 
                                                          - Warp

Post a reply to this message