Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: Re: Seeking critique(s) of C++ Message-ID: <4620@lupine.NCD.COM> Date: 25 Mar 91 06:31:18 GMT References: <1991Mar20.015750.9487@dbase.A-T.COM> <633@taumet.com> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 57 In article mikeg@c3.c3.lanl.gov (Michael P. Gerlek) writes: > >I've just started playing with C++, and keep hearing that "they say" >C++ won't cut it for codes where performance issues are critical, so >I'm happy to hear "they" may be wrong. So... Well, you know what they say: "All generalizations are false... including this one." :-) >Leaving aside issues of how hard the C code would be to understand, >maintain, debug, etc, does anyone have any details or references on >just how much more efficient C++ code is over C? - runtime peformance, >source/object code size, and so on? When the issue of C vs. C++ performance comes up, the reference most often cited seems to be: A C++ Interpreter for Scheme by Vincent F. Russo & Simon M. Kaplan In: USENIX 1988 C++ Conference Proceedings The authors claim that they converted a system (the Scheme interpreter) from C to C++ and it actually got faster. As one more (albeit less relevant) data point, my protoize program is written in that strange dialect which lies in the intersection of ANSI C and C++, so it can be compiled with either and ANSI C compiler, or with cfront (and then a C compiler) of with g++. Once I tried to compile it all three ways, and then ran `size' on the resulting binaries only to find that the results were virtually identical in all three cases. That's pretty good because it indicates that in C++, you don't really pay any price for features that you don't use. >Do Stephen's claims really hold true using a compiler that *does* go >through intermediate code? At first blush this doesn't seem >intuitive. (A "tight" piece of C++ code has to be translated into a >"tight-with-overhead" piece of C code. What does the "overhead" >consist of?) If you declare virtual functions, you pay the price for those in terms of space because you get space allocated to hold virtual function pointer tables, but if you *use* the virtual functions that you declare, you may be regaining that space elsewhere in your program. >Finally, Stephen says his string processing uses "carefully designed" >management classes. How "careful" need one be in order to exceed the >source and object code size of a traditional C program? I think that you got it backwards. If you are *sloppy* you will "exceed" the source and object code sizes of an "equivalent" C program. -- // Ron ("Shoot From The Hip") Guilmette // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.