Mail Archives: djgpp/1999/08/03/22:17:57
Eli Zaretskii writes:
> People who write C++ usually don't want to restrain themselves like
> that.
>
> FWIW, Groff, the GNU replacement fro the Troff/Nroff package, is also
> written in C++, and it also carefully avoids any expensive C++ features.
C++ in itself is not expensive: the only problem is that it can easily
generate expensive code from what look like simple, harmless actions.
For example a method call involves the overhead of passing an extra
hidden parameter, but this is no loss if you were going to do that
anyway. Calling fprintf(file, ...) is no different to file.printf(...).
And virtual functions are only expensive if you weren't already going
to be using a function pointer or switch statement to do that same
thing.
In other words, it is easier to carelessly produce inefficient code
in a C++ program than it is in C, but if you know and think about
what you are doing, there need not be any performance difference from
using even the most OO features.
FWIW, in my day job I write games for console machines, which have
slow processors and extremely limited memory. Until recently we've
been doing this in C, but are now switching to C++, using it mostly
as an improved C for things like overloaded functions and default
parameters, but with a few C++ classes here and there as well.
This change hasn't made any difference to executable size or
efficiency, but having overloaded classes for things like matrix
and vector objects saves a lot of coding effort.
Of course it is also all too easy to write horrible bloated C++
apps: just look at any Windows program that uses the MFC classes :-)
> You can't even dereference a pointer in C++ without being sure it wasn't
> overloaded by some class that is called deep inside the libraries you are
> using.
For sure: that's why it is important to understand the language,
and know what libs you are using. The same thing goes for C as
well, although to a lesser extent: you can't write efficient code
without understanding the performance implications of whatever
library routines you may be using.
Shawn Hargreaves.
- Raw text -