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". :)
