Date: Mon, 16 Dec 1996 17:50:14 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: Allegro future
In-Reply-To: <csRE8PAcDyryEwpr@talula.demon.co.uk>
Message-ID: <Pine.SUN.3.91.961216174328.18715L-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Wed, 11 Dec 1996, Shawn Hargreaves wrote:

> >One word: speed.  OO is slow.
> 
> <enter holy war mode>
> 
> I don't believe that, as long as you know what you are doing and only
> use OO features where they are appropriate. Most of the things that
> cause overhead (passing the 'this' pointer to member functions, calling
> virtual functions, etc), should only be used if they are needed, in
> which case they replace another construct which would have produced
> exactly the same overhead in C. Of course, it's easy to write bad, slow
> C++ code, but that is true of any language.

I'm NOT in holy war mode here, mind you.  IMHO, the real problem with C++
is not the code *we* write (upon which we have *some* control), but the
code that is inside C++ class libraries which most people will use without
looking up the sources.  Now, while in C you will usually have an
intuitive notion of how expensive a given operation should be, in C++ this
is generally concealed in the inheritance hierarchy, and is beyond your
grasp (unless you really trace the source code).  For example, in C, I
_know_ that a pointer dereference cannot be too bad runtime-wise; but in
C++, some class somewhere deep in the inheritance hierarchy might have
overloaded the `*' operator and when I dereference a pointer, I'm actually
launching an iterative integrator of a differential equation...