Mabden said:
And it is wrong. Read "The Design and Evolution of C++" b Bjarne
Stroustrup.
Pg. 28:
"The explicit aim was to match C in terms of run-time code..."
"To wit: Someone once demonstrated a 3% systematic decrease in overall
run-time efficiency compared with C caused by the use of a spurious
temporary introducuced into the function return mechanism by the C with
Classes (FYI: precursor to c++) preprocessor. This was deemed
unacceptable and the overhead promptly removed."
The basic tenet of C++ is to be a better C, and to not add overhead into
programs that do not use C++ features.
Anything you believe about "hidden costs" are similar to your beliefs
about UFOs and gods. Ie: non-existent.
Well, no. Anything you believe about "hidden costs" are similar to
whatever other beliefs you can prove or disprove by reproducible
experiment. And experiments repeatedly show varying nonzero costs
intrinsic to C++ that are not present in C.
Exception handling is an obvious case in point -- the implementation
can effectively eliminate performance costs by raising code size,
or conversely, but the cost is there in some form. You can sometimes
argue that the equivalent checking in C has a nonzero space/time
cost, and that is true; but whether the costs are comparable depends
strongly on the particulars of a program. You can also argue (as
above) that the extra costs are being steadily eliminated as they
are discovered, but that is only true up to a point. It's fun to
highlight the successes, less fun to admit the failures (so far)
to eliminate extra overheads.
Virtual function calls raise issues similar to those for exceptions,
but typically with much smaller costs. OTOH, input/output using
the Standard C++ library drags in *way* more code than does the
Standard C library for (loosely) comparable operations. And the
I/O performance gap has closed dramatically over the past decade,
but it's still there.
Then there's the oft-repeated mantra that C++ can be *more*
efficient than C; and occasionally that's doubtless true.
But on average, IME, a C++ program will be 5 to 15 per cent
larger and/or slower than a comparable program written in C.
Again IME, that's a price well worth paying, in practically
all cases, for the improved productivity that you can get
by writing large programs in C++ instead of C. Historically,
C began winning over assembly language when its extra overhead
dropped to about 30 per cent. It's a rare application, even
embedded, where even 50 per cent overheads are worth addressing
by going to lower-level coding techniques. It's way cheaper to
use faster or bigger hardware, even when you're shipping
hundreds of thousands of devices.
I consider it a mark of zealotry to pretend that there are
*no* additional overheads when using C++ instead of C. That
requires a leap of faith akin to believing in UFOs and gods.
But more important, you don't have to be a C++ zealot to
decide on the basis of reasonable evidence that it's well
worth the real and measurable costs that are still there.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com