Re: C++ vs C compiler on size

aeb@saltfarm.bt.co.uk (Tony Bass)
16 Jan 1997 11:18:30 -0500

          From comp.compilers

Related articles
C++ vs C compiler on size yeh@netcom.com (1997-01-07)
Re: C++ vs C compiler on size robison@kai.com (Arch Robison) (1997-01-09)
Re: C++ vs C compiler on size fjh@mundook.cs.mu.OZ.AU (1997-01-12)
Re: C++ vs C compiler on size bill@amber.ssd.csd.harris.com (1997-01-12)
Re: C++ vs C compiler on size jlilley@empathy.com (1997-01-12)
Re: C++ vs C compiler on size schow@nortel.ca (Stanley Chow) (1997-01-14)
Re: C++ vs C compiler on size jwdonah@ibm.net (Joseph Donahue) (1997-01-14)
Re: C++ vs C compiler on size aeb@saltfarm.bt.co.uk (1997-01-16)
Re: C++ vs C compiler on size edi-c@algonet.se (Kurt Svensson) (1997-01-16)
| List of all articles for this month |

From: aeb@saltfarm.bt.co.uk (Tony Bass)
Newsgroups: comp.compilers
Date: 16 Jan 1997 11:18:30 -0500
Organization: BT Speech Technology Section
References: 97-01-090
Keywords: C, C++, performance, comment

  Arch Robison wrote:
>> [1] Separate discussion issue: Is it theoretically possible for a C++
>> compiler to always generate machine code linear in the size of the
>> source? If so, is the theoretical implementation practical?


jlilley@empathy.com (John Lilley):
> Gee, I know we're gonna open up a big long thread with this one...
> Theoretically, of course you can ;) You generate an executable that
> contains a C++ interpreter, which is presumably of fixed size, and the
> source code. Not very practical though. I am guessing when I say
> that it can be done practically as well, given that template expansion
> usually results in very similar sets of code that a plausibly
> intelligent compiler/linker could merge the similar cases. But I'm
> grasping... The complexity of the type interactions in the template
> code, make it so darn hard to merge the resultant specializations.




Complex indeed. Another point is that the preprocessor could cause
exponential expansion of ordinary code with something like


      #define Two(p) ((p),(p))
      int x = 0;
      ... Two(Two(Two(Two(++x)))) ...


so one probably wants to disregard this sort of thing and take compiler
to mean without preprocessor.


With templates, suppose one deliberately recurses,


      template<int N> struct Rep {
        Rep<N-1> rest;
        int x;
        Rep() : x(rest+1) {}
        operator int() { return x; }
        };


      struct Rep<0> {
        Rep() {}
        operator int() { return 0; }
        };


      int main()
      {
        return Rep<5>();
      }


Each Rep<i> has its x at a different offset (or if not then we could
make it worse with one int field before and one after the recursion), so
it looks quite difficult for a code generator to merge levels.


        Tony Bass


--
# Tony Bass Tel: (01473) 645305
# MLB 3/19, BT Laboratories e-mail: aeb@saltfarm.bt.co.uk
# Martlesham Heath, Ipswich, Suffolk, IP5 7RE
[The preprocessor example doesn't count, since it's not valid C or C++ (and
I don't know of any way to write recursive preprocessor macros that expand
a finite amount), but the template looks real. -John]
--


Post a followup to this message

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