Re: Templates in C++

bill@amber.ssd.hcsc.com (Bill Leonard)
Fri, 30 Jun 1995 18:06:08 GMT

          From comp.compilers

Related articles
[6 earlier articles]
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)
Re: Templates in C++ kanze@gabi-soft.fr (1995-05-29)
Re: Templates in C++ mac@coos.dartmouth.edu (1995-06-23)
Re: Templates in C++ shankar@sgihub.corp.sgi.com (1995-06-25)
Re: Templates in C++ bill@amber.ssd.hcsc.com (1995-06-30)
Re: Templates in C++ collberg@cs.auckland.ac.nz (1995-07-12)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bill@amber.ssd.hcsc.com (Bill Leonard)
Keywords: C++, performance
Organization: Harris Computer Systems, Ft. Lauderdale FL
References: 95-05-081 95-06-026
Date: Fri, 30 Jun 1995 18:06:08 GMT

  mac@coos.dartmouth.edu (Alex Colvin) writes:
> One of the things that forces recompilation of C++ programs is that
> class definitions must list all their (private) members.
>
> Is the main reason for this the need for structure sizes at
> compile-time? Would link-time be sufficient?


It could be done, but at a great cost in performance.


> Could structure and stack frame sizes be computed at link time as the sum
> of constants generated by separate compilations?


These are not the only things affected by structure sizes. For example,
suppose you have a variable of class A that contains a member of class B.
If you don't know class B's size, then you also can't compute the offset
within class A of members that come after the B member. This makes it
difficult to generate code to access those members (or, alternatively, you
could simply say that the code will be sub-optimal all the time).


Another problem is maintaining alignment. If you don't know what the
members of B are, how can you know what alignment they require? As a
consequence of not knowing, you'd have to assume the worst case, which
could waste quite a lot of space.


Also, on some architectures, one must generate special code to access local
variables whose stack-frame offset is larger than a certain value (say
2^16). If you don't know the sizes of some local variables, then you'll
always have to generate such code for some of the locals, and this will in
turn give very poor performance.


A clue to the cost of deferring such decisions can be gotten by looking at
Ada. Ada has data types whose sizes are dynamic. The code generated for
procedures that have local variables of such a type is quite a bit worse
than code for a similar procedure whose variables are all statically-sized.
Similarly, records containing such types incur more cost to access the
elements.


Your suggestion would, in fact, result in even worse code than what Ada
generates, because at least Ada knows *something* about the types -- i.e.,
it knows the types of the *potential* members of a variant record and the
types of the elements of dynamic arrays, it just can't statically know the
size of the complete aggregate. In the case of deferring the knowledge
about private members in C++, you know *nothing* about their types.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--


Post a followup to this message

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