lsr@Apple.com (Larry Rosenstein) (01/24/91)
In article <5672@rex.cs.tulane.edu>, mandel@vax.anes.tulane.edu (Jeff E Mandel MD MS) writes: > > From: Reid Ellis <aliasbridge!Reid_Ellis.STYLE%alias@VM.TCS.Tulane.EDU> > > >Why is it > > void operator +=( const CString& s1); > >and not > > CString& operator +=( const CString& s1); > >?? > > > > Reid > > The answer is subtle. An operator has access to the object which invokes > it. The operator simply modifies the existing object, rather than > returning a new one. Thus: You could write operator+= either way, depending on what behavior you wanted to provide. For example, for built-in types, you can write something like x = (y += z), which adds z to y and assigns the result to x. If CString::operator+= returns void, then this kinds of statement is illegal. To allow it, you would have operator+= return a const CString&.
rae@gpu.utcs.toronto.edu (Reid Ellis) (01/27/91)
I asked: >Why is it > void operator +=( const CString& s1); >and not > CString& operator +=( const CString& s1); >?? Jeff E Mandel <mandel@vax.anes.tulane.edu> writes: >The answer is subtle. An operator has access to the object which invokes >it. The operator simply modifies the existing object, rather than >returning a new one. But I have it returning a reference [CString & operator+=] not a new object [CString operator+=]. Larry Rosenstein <lsr@Apple.com> writes: >.. you would have operator+= return a const CString&. It 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') ... Admittedly, using the result of += in such a non-const manner is unusual, but I see no reason to forbid it.. 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
lsr@Apple.com (Larry Rosenstein) (01/30/91)
In article <rae.664964603@barney>, rae@gpu.utcs.toronto.edu (Reid Ellis) writes: > > It 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') ... 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. 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). Larry
rae@gpu.utcs.toronto.edu (Reid Ellis) (02/03/91)
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 <lsr@Apple.com> 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