|Templates in C++ firstname.lastname@example.org (1995-05-11)|
|Re: Templates in C++ email@example.com (1995-05-12)|
|Re: Templates in C++ firstname.lastname@example.org (1995-05-12)|
|Re: Templates in C++ email@example.com (1995-05-12)|
|Re: Templates in C++ firstname.lastname@example.org (1995-05-14)|
|Re: Templates in C++ davidm@flora.Rational.com (1995-05-16)|
|Re: Templates in C++ email@example.com (Greg Morrisett) (1995-05-17)|
|Re: Templates in C++ firstname.lastname@example.org (1995-05-17)|
|Re: Templates in C++ email@example.com (1995-05-25)|
|Re: Templates in C++ firstname.lastname@example.org (1995-05-29)|
|[4 later articles]|
|From:||email@example.com (Marc Shepherd)|
|Date:||Fri, 12 May 1995 12:34:32 GMT|
firstname.lastname@example.org (Jeffrey Cohen) writes:
>With all this discussion of the performance differences between
>C and C++, I didn't see one reference to C++ templates. How does
>this effect performance?
>[I was under the impression that the biggest practical problem with templates
>is avoiding redundant instantiation when you have separately compiled modules.
>Other than that, they act very much like macros, which don't present great
>compiling problems. -John]
The other challenge with templates is the "code bloat" that can
result if many very similar templates are instantiated. (I guess you
could call this "performance related," in that it can lead to
In the pre-template days, if you wanted a general linked list class,
you crated a list of generic pointers, and anyone using the class had
to cast their objects to and from void*. (At least, this was one
common way of doing it.) This required lots of unsafe casting, but
only one copy of the list management code was generated.
Now, if you write a linked list template class, and instantiate it
for a variety of object types, every one of those instantiations will
cause a separate instance of the template code to be compiled into
the executable. In applications that make heavy use of templates,
this can be significant.
One way to avoid the code bloat is to organize your code into two
classes-- the template, and a private non-template base class that
does most of the real work. In many cases, the template can be
implemented as a series of inline forwarding functions to the private
base (of which only one copy exists in the executable, since it is
not a template).
If you use this strategy, the space costs of templates are minimized.
Salomon Brothers Inc
Return to the
Search the comp.compilers archives again.