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) |
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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.