Re: Templates in C++

jsgray@ix.netcom.com (Jan Gray)
Fri, 12 May 1995 09:08:06 GMT

          From comp.compilers

Related articles
Templates in C++ jcohen@juniper.tc.cornell.edu (1995-05-11)
Re: Templates in C++ litsios@iis.ee.ethz.ch (1995-05-12)
Re: Templates in C++ jsgray@ix.netcom.com (1995-05-12)
Re: Templates in C++ shepherd@schubert.sbi.com (1995-05-12)
Re: Templates in C++ norman@flaubert.bellcore.com (1995-05-14)
Re: Templates in C++ davidm@flora.Rational.com (1995-05-16)
Re: Templates in C++ jgmorris@cs.cmu.edu (Greg Morrisett) (1995-05-17)
Re: Templates in C++ jplevyak@violet-femmes.cs.uiuc.edu (1995-05-17)
Re: Templates in C++ bill@amber.ssd.hcsc.com (1995-05-25)
[5 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: jsgray@ix.netcom.com (Jan Gray)
Keywords: C++, performance
Organization: Netcom
References: 95-05-081
Date: Fri, 12 May 1995 09:08:06 GMT

jcohen@juniper.tc.cornell.edu (Jeffrey Cohen) writes:
>As an example. If you were generating a matrix class, would better
>code be generated through a generic class or by using a template
>class that has two integers. I think it should be the template
>class since the bounds are known and the compiler can better
>optimise the code. Is this true and why?


Yes, this is true, exactly for the reason you give.


John:
>Other than that, they act very much like macros, which don't present great
>compiling problems. -John]


(Well, implementation-wise, templates are considerably harder.
Consider
    template <class T> class list { ... };
    struct X { ... void f(int i, list<int> li); ... };
Here the compiler is halfway through struct X and suddenly realizes
it needs to know all kinds of things about the type "list<int>". What
do you do?)


John:
>[I was under the impression that the biggest practical problem with templates
>is avoiding redundant instantiation when you have separately compiled modules.


Even without a program database, the redundant instantiation problem
is simple if you can make minor extensions to your linker and object
module format. For Microsoft C++, we already had an object
contribution called a "COMDAT", a named section with semantics that
the linker retains only one instance of any section with that name.
Even if every object contributes the instantiation of
"list<int>::add()" or whatever, the linker only keeps one copy per
binary or dynamic library.


A more common problem with templates is you tend to see many
instantiations of containers of similar types, e.g. list<int>,
list<unsigned>, ..., or worse, Ptr<A>::operator A*(),
Ptr<B>::operator B*(), ..., many of which are in fact bitwise
identical or nearly so. Templates make it all too easy to create
many bytes of code just by naming a new type. Not to mention the
stress n template instantiations make on the other parts of one's
compilation system: bloating the debug information, browse
(cross-reference) information, etc. Although there are several
idioms that can reduce redundant instantiation, they all require
coder effort and experience.


But sure, you certainly can can get some run-time efficiencies you wouldn't
enjoy with more "generic" classes.


Jan Gray
Redmond, WA
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.