Path: chuka.playstation.co.uk!news From: Toby Sargeant Newsgroups: scea.yaroze.freetalk Subject: Re: C versus C++ Date: Fri, 23 Jan 1998 10:32:58 +1100 Organization: Forefront Software Services Lines: 62 Message-ID: <34C7D72A.EA500AB0@forefront.com.au> References: <69cmja$7pn1@emeka.playstation.co.uk> <34b9e34f.14105854@news.scea.sony.com> <34BF10FF.13D7@bc.sympatico.ca> <34C293DF.6237DFF6@forefront.com.au> <34C6E92E.1D33@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) Nick wrote: <...> > >* 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. > > We only use pure virtual methods in game code, and we only did that > after we verified that pure virtual base classes do not > generate vtables under VC++ or Metrowerks. The reason we use > pure virtuals is to enforce an interface. Something you can nowadays > use templates for in some cases. I can't see how this can help completely. Even if the entire base class is virtual, code needs to be generated to determine the actual type of the object called via a base class pointer. Of course if you were writing OO C (don't laugh, depending on your definitions of OO, it's possible), and you were dealing with unnamed types like this, then you'd have to write the same code for yourself, so the loss is smaller than if the compiler generates vtables. > >* 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. > > Danger danger Will Robinson! Passing by const reference has a REALLY > EVIL side effect - the compiler will generate temp references galore! > In a recent game engine, we did a lot of const String& parameter passing > and discovered that VC++ and Metrowerks both generated hundreds of > thousands of copies of the string objects at run time just to make sure > nothing icky happened! This is the biggest C++ gotcha of all time, I > think. > P-YEW! We've banned const Object& parameters since then. This makes me really really scared. I can't see any reason why a compiler would generate code like that. The problem should be with references, and not with the const. Did the compiler generate copies of the string, or copies of the string reference? If it generated copies of the string, then i would consider that a compiler bug, seeing as it means that const casts won't have the correct effect. Passing by const ref is supposed to be much more efficient. Quoting the GotW #2, which agrees with what my hons C++ lecturer, among other people, said, the rules regarding temporaries are supposed to be: [Rule] Prefer passing const& instead of copied values. [Guideline] Prefer preincrement, avoid postincrement. [Guideline] Watch out for hidden temporaries created by implicit conversions. One good way to avoid this is to make ctors explicit when possible. [Rule] Follow the single-entry/single-exit rule. Never write multiple return statements in the same [Rule] Never, ever, EVER return references to local objects. Is it possible to see some code that demonstrates this? toby