Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: Nick Newsgroups: scea.yaroze.freetalk Subject: Re: C versus C++ Date: Tue, 03 Feb 1998 00:32:32 -0800 Organization: SCEA News Server Lines: 54 Message-ID: <34D6D61E.4103@bc.sympatico.ca> 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> <34C7D72A.EA500AB0@forefront.com.au> Reply-To: Nick_Porcino@studio.disney.com NNTP-Posting-Host: vcta01m01-68.bctel.ca Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01-C-SYMPA (Macintosh; I; PPC) >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 vtable Pure virtuals only help if you avoid polymorphism, which I know is one of the big selling points of OO. eg: class VFile { ... }; // pure virtual base class class RealFile : public VFile { ... }; RealFile var; var.Read(); Read is invoked directly, and no vtable is generated. Like I said, we only use this feature to enforce interfaces, much like Java's interface keyword. Yes, now that I'm typing it, I wonder what's the point, documentation and a whip to enforce the interface would accomplish the same thing. I guess it's just a lazy way to get the compiler to make sure you're doing the right thing. Lazy. >[The const ref thing] 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? Copies of the string. The problem is that with a complicated enough class (like a full feature string) the compiler is unable to determine whether or not the string might be modified by a method (the halting problem in a different form), and since the const keyword is there, the compiler is compelled to guarantee absolutely that the string will not be modified, so it has no choice but to generate a duplicate. If you want to see the problem in action, get a nice complicated string class like the one in MFC, get a nice complicated function which uses a string, and pass the string in as a const ref. Unless they've done something marvelous in MFC, the compiler will likely dup it. Giving it a little thought, the problem boils down to the fact that complicated string classes typically reference count a string representation, and assign the same rep pointer to any string that takes a copy. The reference count has to be incremented, which violates the const rule that the object passed in via the reference cannot be modified. So maybe the compiler is barfing because of the overloaded = operator. So that would be the code example - a class that has non const overloaded = operators, and a method that assigns an instance of the passed in const ref class to another instance. So maybe it's not the halting problem, maybe the compiler can detect that combination and try to protect against it. Performance wise, passing by & is exactly equivalent to pass by pointer. - nick