Re: is C necessarily faster than C++

bill@amber.ssd.hcsc.com (Bill Leonard)
Fri, 30 Jun 1995 20:27:29 GMT

          From comp.compilers

Related articles
[20 earlier articles]
Re: is C necessarily faster than C++ calder@mumble.cs.Colorado.EDU (1995-05-09)
Re: is C necessarily faster than C++ schow@bnr.ca (stanley (s.t.h.) chow) (1995-05-09)
Re: is C necessarily faster than C++ mike@vlsivie.tuwien.ac.at (1995-05-04)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-05-16)
Re: is C necessarily faster than C++ itcp@praxis.co.uk (1995-06-23)
Re: is C necessarily faster than C++ jplevyak@violet-femmes.cs.uiuc.edu (1995-06-23)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-06-30)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-06-30)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bill@amber.ssd.hcsc.com (Bill Leonard)
Keywords: C, C++, performance
Organization: Harris Computer Systems, Ft. Lauderdale FL
References: 95-04-202 95-06-040
Date: Fri, 30 Jun 1995 20:27:29 GMT

itcp@praxis.co.uk (Tom Parke) writes:
> In general when comparing programming languages it is important to
> focus on how they are actually used, not how they could be used or to
> compare features at too low a level.


Maybe, but I don't think it is a fair (or useful) comparison if you include
misuse of a language. For instance, if a programming makes *every*
function virtual in C++, he's misusing the language and deserves whatever
poor performance he gets.


> In this instance I would claim that in practice the C equivalent of
> a class with a virtual function and a number of different classes
> derived from it is actually a number of different modules with
> possibly some common code factored out. The programmer avoids the need
> for a switch statement by explicitly calling the version of the
> function he requires.


Yes, but let's not forget that no matter *how* you code those modules
in C, somewhere there's going to be some decision-making code that takes
the place of the virtual function mechanism.


> Now a C++ advocate could argue that its no longer a fair comparison,
> but if the C++ advocate is also going to argue that C++ code makes
> re-use possible and is easier to maintain and extend then he/she has
> to accept that these claims assume that the C code isn't written in a
> pseudo C++ style which is what I think Bill Leonard is assuming in his
> comparison.


I'm not sure I even understood that statement, but I think it is not true.


All I am saying is that it is not fair to compare a C function to a virtual
C++ function that does the same thing. Calling the C++ function incurs
some overhead, but unless the programmer made it virtual unnecessarily,
that overhead WAS DOING SOMETHING USEFUL. It was making a decision, and
one must presume that a similar decision would have to be made if one coded
the application in C.


Just as an example, one might have 3 different C++ classes that implement
virtual function Foo differently. In calling this function, the virtual
function mechanism will chose one of 3 different Foos. I assume that there
is some underlying reason for needing to choose among one of 3 different
actions at that point in the application.


Now consider what the equivalent C code would have. Somewhere, this
decision among 3 different actions must be made. Where is that code?
Probably a switch statement or an if-test.


Therefore, in doing the comparison, one must include that decision-making
code in the C part of the equation. Otherwise, you're not comparing apples
to apples.


--
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.