Path: utzoo!mnetor!tmsoft!torsqnt!geac!alias!barney!rae From: rae@gpu.utcs.toronto.edu (Reid Ellis) Newsgroups: comp.sys.mac.programmer Subject: Re: C++ CString sample code Message-ID: Date: 2 Feb 91 21:16:06 GMT References: <5672@rex.cs.tulane.edu> <11830@goofy.Apple.COM> <11904@goofy.Apple.COM> Sender: Reid Ellis Reply-To: Reid Ellis Organization: Alias Research, Inc. Toronto ON Canada Lines: 38 I wrote: |[operator+=] shouldn't be const. If you are using operator+=() as |defined above, you do not have a const object, and a method shouldn't |"make" it const for no good reason. e.g., defining operator+=() as |returning a "const CString &" would make the following illegal: | | if((cstr += otherCstr)[12] == '\n') ... This wasn't a very good example :-) A correct example would be (str += str2)[14] = 0; Larry Rosenstein writes: |Not necessarily; it depends on the declaration of CString::operator[]. That |method doesn't change the string, so it could be declared as a const |member function. In that case, the construct above would be legal. |Certainly, other constructs would be illegal (eg, str1 += str2 += str3). | |First, you aren't changing the object into a const object. You are simply |affecting the result of operator+=. All you are doing is preventing |more than 1 modification in the same statement. The point I failed miserably in making :) is that the integral types native to C++ [int, float, char etc] define operator+=() on their type such that the return value is non-const. Making it const in CString is non-intuitive, and might break code that would othersize work based on the assumption that CString would try to act the same as int, float et al. I feel that it is unwise to change the behaviour of an operator compared to the behaviour of that operator w.r.t. built-in types, that's all. Reid -- Reid Ellis 176 Brookbanks Drive, Toronto ON, M3A 2T5 Canada rae@gpu.utcs.toronto.edu || rae%alias@csri.toronto.edu CDA0610@applelink.apple.com || +1 416 446 1644