Operator overloading -- lets collect some use cases

[Weed]

Don пишет:
> Weed wrote:
>> Don пишет:
>>> Weed wrote:
>>>> Frits van Bommel пишет:
>>>>> Don wrote:
>>>>>> Frits van Bommel wrote:
>>>>>>> Don wrote:
>>>>>>>> A straightforward first step would be to state in the spec that
>>>>>>>> "the
>>>>>>>> compiler is entitled to assume that X+=Y yields the same result as
>>>>>>>> X=X+Y"
>>>>>>> That doesn't hold for reference types, does it?
>>>>>> I thought it does? Got any counter examples?
>>>>> For any class type, with += modifying the object and + returning a
>>>>> new one:
>>>> The += operator too should return the object (usually "this")
>>> ALWAYS 'this'. It's another feature of operator overloading which is
>>> redundant.
>>
>>
>> Not always. Can be more convenient to create the new object and to
>> return it.
>>
>> For example: if it is necessary to return the object containing the
>> sorted data those sorting hurriedly at creation of the returned object
>> can give a scoring in performance than if the data is sorted in the
>> current object after their change.
> But then if you have
>  y = x+=b;
> 
> surely that would give you x and y being different?
> Wouldn't you want x to also point to the new object? (OK, as Stewart
> pointed out, you can't!) Otherwise, you have to perform _both_ sorts!

I agree, my point of view disputable.

The programmer can have a desire to return not current object: the
returned and this will be equivalent but are not identical. Do not
forget that this object may be not a class - it can be struct and such
return can in certain to save a few resources.
But if us will force to return this under the threat of a compile error
I will not cry.:)

And you have certainly noticed that here the solution inaccuracy again
appears to divide structures and classes by a principle "on value" and
"reference". :)