Operator overloading -- lets collect some use cases

Don nospam at nospam.com
Mon Jan 5 00:28:11 PST 2009


Weed wrote:
> Don пишет:
>> Weed wrote:
>>> 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". :)
>> Yah. They're almost the same, but not quite. It's interesting that value
>> semantics are IMPOSSIBLE with classes (I didn't know that until
>> Stewart's post), whereas reference semantics with structs are possible
>> (but ugly) with structs.
>>
>> In my experience with D, I use structs + templates far more frequently
>> than classes + polymorphism. And I suspect that if interfaces were a bit
>> more powerful and efficient, struct+interface might replace even more of
>> the use cases for class-based run-time polymorphism. So I must admit,
>> I'm quite biased against classes.
> 
> I am absolutely agree with that that the interfaces too are necessary
> for structs.
> 
> But whether you by means of templates and mixin repeat an OOP
> programming paradigm?

I generally use compile-time polymorphism rather than run-time.
But there's an interesting question: using opDot() and mixins, how close 
can you come to implementing classes?
A particularly interesting case is the GoF Strategy pattern, where 
derived classes add no data, they only override virtual functions.
The slicing problem never happens with such objects, provided that you 
include the vtable pointer when you copy the object.
Sounds like you want one struct + multiple interfaces.



More information about the Digitalmars-d mailing list