Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: matth@bellatlantic.net (Matthew Hulett)
Newsgroups: scea.yaroze.freetalk
Subject: Re: C versus C++
Date: Fri, 16 Jan 1998 04:05:33 GMT
Organization: SCEA News Server
Lines: 54
Message-ID: <34bedbca.12413714@news.scea.sony.com>
References: <69cmja$7pn1@emeka.playstation.co.uk> <34b9e34f.14105854@news.scea.sony.com> <34BF10FF.13D7@bc.sympatico.ca>
NNTP-Posting-Host: client-119-23.bellatlantic.net
X-Newsreader: Forte Free Agent 1.11/32.235

   Nick,
  Two cents? That answer was worth it's weight in gold. The only
question I am left with is: Since a developer uses C++ for certain
features, is his goal always to try to optimize it so that it's
performance equals C, i.e. C++ does not offer any speed advantages per
se, you only wish for the features it offers, and you must work to be
able to use those features without compromising performance? I hope
that is a clear question...
   Gratefully,
   Matt

>Chris is out of town this week. I work with him, so I'll throw in my two
>cents for what it's worth. 
>
>One note is that we only hire programmers fluent in C++.
>
>As far as efficiency goes, I've taken a sprite rendering routine written
>in C, hand translated it and optimized it in assembly, then compiled the
>C code in Metrowerks C and in C++, and found that my routine was the
>fastest, no surprise, but the C version had almost equivalent
>performance because the compiler knew a few scheduling tricks I didn't.
>As for C++, the EXACT SAME CODE was generated. Mind you, I wasn't using
>any C++ specific language features, although the routine was a member of
>a class in the C++ version.
>
>Some C++ constructs like exception handling can cause extreme
>performance degradation, depending on the vendor. Metrowerks generates
>very low overhead exception handling code. Visual C++ OTOH causes an
>overall 25% code bloat, and at least an overall 25% slow down in
>generated code. I kid you not.
>
>Other problematic C++ features like the freakish amount of
>construction/destruction that goes on can be avoided if you understand
>the semantics of const references. If you use a clever memory allocator
>that doles out objects from an array, and never invokes
>construction/destruction code, C++ works just fine on consoles because
>you can avoid the biggest C++ bugaboo - memory fragmentation.
>
>I've recompiled the BallTest demo using the Metrowerks C++ compiler and
>get the same framerate as compiling as a C project.
>
>I'm 100% convinced that no matter what anyone says, it is possible to
>write C++ that executes as quickly as a decent C implementation would.
>Unfortunately, it took several years for me to get good enough to
>actually be able to say that.
>
>Finally, my recommendation if you're just learning to program, is to
>learn C so you have a good solid language that you can get great mileage
>out of, then learn Java to get a good grounding in object oriented
>techniques, threading, and the like, then learn C++ if you are hoping to
>work in a shop that specializes in C++.
>
>- nick