Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: "Michael C. Lee, Jr." Newsgroups: scea.yaroze.freetalk Subject: Re: object-oriented support? Date: Thu, 24 Jul 1997 08:52:46 -0700 Organization: SCEA Net Yaroze News Lines: 110 Message-ID: <33D77A4E.3BDB@hubcap.clemson.edu> References: <33b69d9c.138132316@news.scea.sony.com> <5p81kr$fv57@chuka.playstation.co.uk> <33D702CE.22A9@hubcap.clemson.edu> <5r7c25$5na47@chuka.playstation.co.uk> NNTP-Posting-Host: pm4-3.innova.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (Win95; I) Gil Jaysmith wrote: > > "Michael C. Lee, Jr." wrote: > >DONT USE C++!! > >Too much overhead. > >Trust me. > > Trust me, squire, what you learnt in school doesn't cover half the > interesting optimisations you can make in C++. > > Sometimes you need compiler support, sometimes you don't. To give one > compiler-specific example, GNU C++ supports an extension declaring the > return object to be a local variable. In other words, the compiler > avoids creating a temporary for transferring back the result. > > More generally, the sensible use of references also avoids temporary > object creation. (Which is of course why references exist :) > > Anyway, for efficiency's sake constructors should do the minimum > amount of work, since they can't return a result code. (The only > result code you'll get is from the 'new' operator, if that's how you > created your object.) If you need a temporary object, use an empty > constructor, and fill in the bits you need only when you need them. > The 'real' data construction can be handled by an Init method or > suchlike. Making your constructors and destructors inline will add to > their speed; frequent function calls cause the problematic overhead. > > For an educational experience which amongst other things demonstrates > how to second-guess the compiler (not that a few small tests won't > show up how to take advantage of your particular compiler's ideas > about code generation) you could take a look at Ellis/Stroustrup's > "The Annotated C++ Reference Manual" (Addison Wesley, ISBN > 0-201-51459-1). > > (This, like Stroustrup's other C++ book, is also a useful book to read > if you're at all in need of humility concerning your programming > ability, since Stroustrup is one of those people who talks of > month-long programming projects as 'exercises for the reader' and > 'useful scaffolding which can be implemented without difficulty'. > ARGH!!!) > > Also, trust me (again!), the overhead of using C++ for your game > manipulation is trivial compared to the overhead of using inefficient > graphics routines and bulk data processing code - which you lucky > Yaroze programmers are condemned to do because of the absence of > documented GTE library support. Most gameswriters would rather have > 95% of their code running 5% less efficiently than face inordinate > hassles trying to organise 100% of their code without the structural > advantages and improved clarity of expression which C++ offers. > > There are several games out there written in C++, and I'm certainly > getting far more support calls for C++ compared to, say, six months > back, and could name half a dozen C++ games due out in the next few > months. It isn't just me bangin' away about C++ being handy! > > Incidentally, half of "Crash Bandicoot" is written in LISP. What did > your school test say about LISP's efficiency? :=) > > Gil Jaysmith > SN Systems Software Ltd, makers of Psy-Q... http://www.snsys.com > Disclaimer: What I say when I post here represents me, not my employers. Like I said, say what you will. Just do a test and see how many times a new object is allocated and deallocated. This was hard learned through many long, late nights in the lab. And the loss was MUCH greater than 5%. This is why I do not use C++ for games. I'll tell you where C++ comes in handy... For a better, more robust design, such as a database where an ER or DFD can be more easily represented with C++, smalltalk or other such oop languages. C++ is bad for games, period. Hardware has gotten MUCH faster and compensated well for this, but when it comes to game, any good coder know that you squeeze what you can out of it. And inlining constructors and destructors won't matter. The compiler does what it wants anyway. I've DONE IT! Go ahead if you want mondo overhead. Don't trust me, take a look at the number of times a temporary object is created for a small task. You will be very surprised I'm sure. Don't get me wrong, I like C++ for what it is good at (Hell, I even like smalltalk and smoked all my classmates consistently in OOP design and coding (different class)), taking something from design to product. It is quicker, easier to read, and more robust than C generally, but it is slower, period, and a good deal more than 5%. More like 15-20 conservatively. Once again, don't take my word for it, check some of your already existing code for the number times a new temporary object is created. Open it in a profiler, put a breakpoint on the constructor and open it in the debugger, whatever, just DON'T trust me. Trust what exists. Bad for games. Bad. True, compiler technology is getting better, but if that were a truism, assembly would not still be as prevelant in games (and I HATE ASSEMBLY). later, mike Incidentally, what did your school teach you about Smalltalk? Or oop design? Or compiler technology and design? As for LISP, what does that have to do with anything. They can write Crash Bandicoot in interpreted REXX for all I care. I'm just trying to help. Considering this is just a hobby thing. Go ahead, C++ your brains out and have slower code. l8r mike 8O