Proposal: Operator overloading without temporaries

[Don Clugston]

James Dunne wrote:
> 
> While being well laid out and well thought through, this proposal still 
> screams to me that it's concentrating on the mathematical problem 
> domain.  This is fine for assuming that classes implementing operators 
> will be mimicing real-world mathematical entities, such as vectors, 
> matricies, etc.  But will this affect other problem domains adversely?

I don't know - but I don't think so. My feeling is that if it strays too 
far from a mathematical domain, it probably shouldn't be using 
overloading of the arithmetical operators. In particular, I think that 
it's very hard to justify a+=b being different to a=a+b.

> I usually like to come from the "everything explicit" angle and don't 
> want the compiler making decisions on my behalf; especially when I'm not 
> aware of them. 

I'll take this as another vote against (III).

My suggestion would be to add a keyword in the operator
> definition (or class definition) to indicate that you want this sort of 
> operator overloading behavior, such that one could leave it off if the 
> default behavior is desired for other such cases.


> In what specific problem domain are you experiencing issues with the 
> current operator overloading syntax/semantics?  Or is it just that you 
> feel that the current syntax/semantics are not quite fully developed?

I was specifically interested in linear algebra. In thinking about 
Norbet's matrix proposal, I was thinking that it doesn't make sense to 
work on the syntax when there's an inherent inefficiency underneath.
Ultimately, operator overloading is just syntactic sugar for function 
calls. The problem with the C++ approach is that it only provides 
function calls for two of the three situations. Consequently, you suffer 
an unnecessary performance hit every time you use operator +.


> And last but not least, another problem is in the order of evaluation 
> for the operator overload calls.  What do you propose for this?  I think 
> in order for this _not_ to matter, you'd have to guarantee that the 
> classes themselves are self-contained and would have no references to 
> (or have any effect on) the other classes involved in the expression 
> statement.

True, but I think this already applies to operator +.

> This brings me to another related issue: these temporaries are going to 
> be allocated on the GC heap no matter what, correct?  What if a silent 
> out-of-memory exception was thrown from a line of code appearing to have 
> no effect on memory allocation whatsoever?

Again, this already applies to opAdd. The only thing this proposal 
changes is that avoidable temporaries are not created. Unavoidable 
temporaries are unchanged.
You raise a good point, though -- unavoidable temporaries could be 
treated better (eg with memory pools), this proposal does not let you 
distinguish between "new temporary = a+b " and "new result = a+b", the 
former could be stored in a memory pool. I think that's a minor issue, 
though.

> There's basically no control over the number of temporaries that could 
> be generated.  Also, there'd be "no going back" from a GC to a manual 
> allocation strategy (i.e. memory pools) because you've effectively lost 
> handles to those blocks of memory for the temporaries.  One could use 
> custom allocators on the class for this purpose, but that would have an 
> adverse effect on normal usage of the class.  These findings lead me to 
> believe that classes which overload operators should have the 
> requirement of being 'auto' (as in RAII or RR).