Re: is C necessarily faster than C++ - comp.compilers #7069

David Toland <>
Thu, 20 Apr 1995 13:01:30 GMT

          From comp.compilers

Related articles
Re: is C necessarily faster than C++ (1995-04-20)
Re: is C necessarily faster than C++ - comp.compilers #7069 (David Toland) (1995-04-20)
| List of all articles for this month |

Newsgroups: comp.compilers
From: David Toland <>
Keywords: C, C++, performance
Organization: Compilers Central
References: 95-04-123
Date: Thu, 20 Apr 1995 13:01:30 GMT
(Jan-Peter de Ruiter) writes:
> tbrannon <> wrote:
> >This guy in my lab keeps refusing to use C++ in our program intended
> >to simulate somatosensory neural circuits because he says it is slower
> >than C. My (uninformed) response was that most of what you see as
> >overhead (ie, message routing, value accessing, type checking) is
> >optimized away at compile-time.
> [C]onstructing
> and destructing local complex objects takes a lot of malloc-ing and
> free-ing. Experienced C programmers having to write efficient code
> usually avoid many calls to malloc by fooling around with pointers
> and keeping track of allocation themselves.

But remember that you can also create your own new and delete operators
for the class.

> In a way it's like the shortcuts
> one can take using assembler. Using assembly language can give you
> a certain performance advantage, but you have to pay more attention
> to the dirty details.

The whole business of rejecting the language because of reputed inefficiency
is a smokescreen anyway, a cheap rationalization that should have gone
out the window when we stopped coding *everything* in assembler. It's
far more important to use a language with expressive power to move closer
to the problem space, and concentrate on the high level algorithms.
That's where you generally get your big performance improvements.
When your program is essentially complete, THEN you go in and profile it
to find the performance bottlenecks. Since you haven't frittered away
your time optimizing the parts that have little effect on the overall
performance, you should now have plenty of time to focus on the places
where the program actually IS spending most of its time.

Of course, there are guiding principles in C++ as in any other language
to avoid wasted cycles, particularly watching for unnecessary copies
and constructions, but this is part of mastering the language.

(Dave Toland)

Post a followup to this message

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