On Tue, 5 Nov 2002 20:18:47 +0900, Brian Candler wrote:
> On Mon, Nov 04, 2002 at 10:02:12PM +0900, Gavin Sinclair wrote:
> (an all-encompassing statement if ever I saw one :-)
>> a += b is always, by definition, in any language, the same
>> *behaviour* as a = a + b. If you disagree, you are being absurd.
> By whose definition? Certainly not the language designers and
> standards bodies. As a counter-example: in C++, if an object has
> both "+" and "+=" methods, the language definition does not
> require them to have the same behaviour, and therefore in general
> they don't. QED.

Actually, it's arguable C++ *the language* (like C) defines a=a+b
and a+=b to have identical behaviour. I read Gavin's statement to be
s statement about the native language support. += is overridable in
C++ for performance reasons -- and for no other reason.

So yes, the language definition for C++ somewhat requires that a+=b
have the same behaviour as a=a+b, and it does so for all primitives;
I'm pretty sure that none of the STL supports a+=b != a=a+b.

The only place where I really disagree with Gavin's statement is
that it's not 100% identical behaviour. Because += is there for
performance reasons, and we know that the object is itself mutable,
it doesn't need to return a reference to a new object in C++, but it
will in Ruby. The *effect* is the same, but the behaviours aren't.

>> The only possible difference is in efficiency: run-time hacks
>> that save an intermediate object. This is a sometimes a valid
>> concern, and there is a remedy: the <<operator.
>>  a = a + b   (old object 'a' lost)
>>  a << b      (same behaviour, *possibly* more efficient)
>> 
>> This behaviour is defined for Strings and Arrays
> Those two examples do not exhibit the same behaviour in the
> presence of other variables containing references to the same
> object as the original 'a'. That's not a "run-time hack", that's a
> difference in semantics: i.e. "I want to create a new object and
> leave the old one alone", as opposed to "I want to modify the
> object itself". The difference is important and not just one of
> efficiency, unless we know for definite that there are no such
> additional references.

You're right -- this is the case. It's also an important distinction
that needs to be made. In C++, a+=b isn't going to be "safe"; it
will modify the object itself and anything that refers to that
object will be modified as well.

-austin
-- Austin Ziegler, austin / halostatue.ca on 2002.11.05 at 10.03.03