|C++ vs C compiler on size email@example.com (1997-01-07)|
|Re: C++ vs C compiler on size firstname.lastname@example.org (Arch Robison) (1997-01-09)|
|Re: C++ vs C compiler on size email@example.com.OZ.AU (1997-01-12)|
|Re: C++ vs C compiler on size firstname.lastname@example.org (1997-01-12)|
|Re: C++ vs C compiler on size email@example.com (1997-01-12)|
|Re: C++ vs C compiler on size firstname.lastname@example.org (Stanley Chow) (1997-01-14)|
|Re: C++ vs C compiler on size email@example.com (Joseph Donahue) (1997-01-14)|
|Re: C++ vs C compiler on size firstname.lastname@example.org (1997-01-16)|
|[1 later articles]|
|From:||Arch Robison <email@example.com>|
|Date:||9 Jan 1997 21:50:38 -0500|
|Organization:||Kuck & Associates, Inc.|
|Keywords:||C, C++, performance|
>On average, how much bigger the code generated by C++ compiler than C
>compiler? Well, you may answer that this depends which compiler is
>used and what C++ features are used. Assume we have C code, we use
>both C++ and C compiler. Is the size of the generated code supposed to
The size should be the same for C code, unless the linker is sloppy
and brings in part of the C++ run-time library. C++ is designed with
a "pay for what you use philosophy". There are compromises in its
design so that C source code compiles into C object code.
>If the answer is positive. Then here is the interesting question:
>How much overhead we have to pay if we need:
It depends upon how these features are used, and what "overhead" means.
The "overhead" depends upon what is considered the "baseline".
There should be no cost for non-virtual inheritance. From the
viewpoint of implementation, non-virtual inheritance is syntactic
sugar for nested structures. There is a cost (extra indirection or
table lookups) for virtual inheritance.
>2. virtual functions?
When someone claims that virtual functions are expensive (or cheap),
you have to ask what they are comparing them against. If comparing
against non-virtual non-inline function calls, the cost is an extra
level of indirection (and possibly another table lookup). This
overhead is usually swamped by the overhead of the call itself. For
inline functions, the cost is that making a function virtual often
(but not always) precludes inlining the functionprecluded, and in that
situation the overhead can be very high.
If comparing against the equivalent multiway branch statement, the
cost of virtual functions can be quite high because optimization of a
multiway branch requires only intraprocedural (single function)
analysis, but optimization of virtual functions require
interprocedural (cross module) analysis.
The code-size cost of templates can range from 0 to exponential.
Programmers have to be fairly deliberate to get the exponential
blowup. Unfortunately, C++ beginners who first start using templates
often write codes with linear or polynomial blowup from templates.
C++ templates give programmers a powerful industrial cookie cutter
which, in the hands of novices who do not see the cookies spewing
forth, makes programs fat. Experienced template programmers know how
to make fat-reduced cookies.
To oversimplify a bit, the problem is that templates are glorified
macros, and generate specialized code for each instance. There are
articles on how to use templates judiciously, and not pay any overhead
. The usual trick is to write templates as inline typesafe
interfaces to untyped implementations. Then the template instances
share the same piece of code, but with the advantage that the
templated interfaces do type checking.
Deviously written macros can also generate exponential code size for
C. But such macros are so ugly that programmers usually have to be
quite deliberate to cause the problem.
Summary: the overhead depends upon the code in question and the
"baseline" being compared against.
[Advertisement] If you want, you can measure the overhead of C++ vs. C
for your applications with our C++ compiler. 30-day trial copies can
be downloaded from the Web page at the end of this note. If you find
an overhead for C compiled with our C++, I certainly would like to
hear about it.
Arch D. Robison Kuck & Associates Inc.
firstname.lastname@example.org 1906 Fox Drive
217-356-2288 Champaign IL 61820
Lead Developer for KAI C++ http://www.kai.com/C_plus_plus/index.html
 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?
 Perhaps someone reading this can provide references on fat-reduced
use of templates?
Return to the
Search the comp.compilers archives again.