Re: Templates in C++

jcohen@juniper.tc.cornell.edu (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? Is the performance highly dependent on
|> the compiler used or are the algorithms for compilation similar
|> across compilers? Do these problems get worse when templates
|> are used recursivly? As parent classes? With multiple parameters.
|>
|> 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?




I suppose this is more a C++ question but it is true that when it
comes down to efficiency the compilers are really the problem.


What templates allow you to do that macros do not is to delay the
evaluation of your operations by storing them in on-the-fly generated
proxy classes. Some time ago vandevod@pleiades.cs.rpi.edu (David
Vandevoorde) posted a nice example of this in comp.lang.c++ for
vector operations. The idea is basically to overload operators to
return a class that knows how to evaluate the arguments in different
ways but doesn't yet do the evaluation. Example:


template<A,B>
ProxyPlus<A,B> operator+(A &a, B&b){ return ProxyPlus<A,B>(a,b); }


The result of an expression of many opeations is a very large class
that knows how to do different things but which one will be used is
not yet decided. It is only at the use of the class that a choice is
made of which of the functionalities to call. All these classes can
be inlined and good optimizers can produce pretty nice results but
where the compilers fail is with the allocation of temporary space,
large amounts of temporary data is stored (for the proxy classes) but
in most cases this is not necessary because only the immediate values
in the registers are used.


Note that in complex applications this methodology is really hard to
make work because what you really need is conditional code on the
types. Although this can somewhat be done with constant static
member values to differentiate the proxy classes most compilers break
down at this point with unimplemented message (or worse).


ps: this is part of that posting


>From: vandevod@pleiades.cs.rpi.edu (David Vandevoorde)
>Newsgroups: comp.lang.c++
>Subject: [Announce] Valarray<Troy> release 1.1
>Date: 10 Mar 1995 19:25:53 GMT
>Organization: Computer Science Department at Rensselaer, Troy, NY
>Summary: New release of numerical array
>Keywords: valarray C++ standard numerical array


>Release 1.1 of valarray<Troy> is now available via anonymous ftp on:
> ftp.cs.rpi.edu
i>n:
> pub/vandevod/Valarray


>Valarray<Troy> is my approximate implementation of the numerical array
>type proposed by the ISO committee for the standardization of C++.


__________________________________________________________________


James Litsios Phone: +41 1/632 60 92
Integrated Systems Laboratory Fax: +41 1/252 09 94
ETH Zurich E-Mail:litsios@iis.ee.ethz.ch
CH-8092 Zurich, Switzerland
--

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