Path: chuka.playstation.co.uk!news From: Toby Sargeant Newsgroups: scea.yaroze.freetalk Subject: Re: C versus C++ Date: Mon, 19 Jan 1998 10:44:31 +1100 Organization: Forefront Software Services Lines: 106 Message-ID: <34C293DF.6237DFF6@forefront.com.au> References: <69cmja$7pn1@emeka.playstation.co.uk> <34b9e34f.14105854@news.scea.sony.com> <34BF10FF.13D7@bc.sympatico.ca> NNTP-Posting-Host: ws19.forefront.com.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (WinNT; I) [sorry, some of this is a little off topic as far as the yaroze goes] Nick Porcino wrote: > 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. How does that compared to the code generated by GCC? Current wisdom seems to be that the GCC codegen is really rather tight. The identical code generation is pretty normal. Essentially if you use C++ as nothing but C with classes, then you can expect that, as a method call is little more than a function call with 'this' as an additional parameter. if the function contains no references to 'this', then the parameter will be optimised away, or if the equivalent C version has to pass an extra struct pointer, then the result will be the same. > 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. Other things that will hurt performance and code size are: * virtual methods These both increase the size and ctor code length of structures, as well as force all method calls to go through an extra table lookup. * passing classes by value This is an extension of the const problem. I'm pretty sure that the compiler can't optimise away const pass-by-value, as that requires making an assumption that the copy ctor doesn't have side-effects. If that's the case, then passing by value will cause much more code execution. Passing by const reference is much more preferable. * templates Templates are evil. 'Nuff said. While they're kind of handy in some places, when memory is a premium, they're really nasty. Other things to watch out for are poor quality 3rd party classes. This isn't a big issue for programming the yaroze, seeing as we don't by default get any. Having the simple stuff written for you in easy to reuse classes is one of the great advantages of object orientedness, which seems to me to be a reason not to write C++ on the yaroze. About a year ago, there was a _great_ series of brainteaserish posts on comp.lang.c++ called 'Guru of the Week' about the pitfalls of C++. They're a great read, even though they're aimed at more general C++ programming. The writer provides C++ snippets with subtle bugs, inconsistencies and inefficiencies, and then, after discussion has calmed down a bit, follows them up with complete descriptions of the problems and suggested solutions. They're not a good way to learn C++, but they're certainly good for improving C++ skills. There's an archive of GotW at http://www.cntc.com > 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. I'll agree completely with this statement. Most of the old C++ compilers worked by converting the C++ to C anyway, and so anything you can think of that has a reasonably trivial mapping from C++ to C will generate similar, if not exactly the same, code. One thing that must be said though, is that to write C++ for speed is often to write C++ like a C programmer, which in some ways defeats the purpose of OO programming. I didn't properly learn the distinction until I came back to OO programming via another language entirely. > 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++. To throw in another opinion here, Python is easily as good a language as Java, in terms of learning Object Oriented programming. While Java is one of the new buzzwords, and is more likely to get you a job (job? who on earth would want on of those...), it owes a lot of its inspiration to C++, and as such is likely to cause confusion and bad OO programming practices, just like moving from C to C++. Python is nice because it has a clean and simple syntax that is easy to learn, and encourages OO programming Toby. -- Toby Sargeant --------------------+ The sun describes its lonely arc, gothic@sirwal.mmcc.monash.edu.au | A brilliant ballet of red and blue, [C|C++|perl|680x0|80x86|lisp|lml] | Drawing the soft mist of starlight [HTML|vim|Linux|python|music|art] | Shivering expectantly in its wake.