current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
stack overflow careers
Sign up ×
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other. Join them; it only takes a minute:
up vote 11 down vote favorite
2

I've always wondered about this for a bit, but why is operator overloading not available for classes in Delphi?

I remember reading an answer once while on the run, and it said it would come in conflict with something, but I can't remember much. As far as I can tell, only the implicit operator may cause a bit of problems since classes are stored on the heap and assigning is actually a copy of the heap address (basically copying pointers).

share|improve this question
1  
It works in Delphi.NET because .NET does garbage collection. This could be solved in the native Delphi in two ways: 1. if operators were allowed on interfaces, and the classes implementing those operator would inherit from TInterfacedObject. 2. if managed classes were added to the Delphi language. Right now, Mason is right: you'd get memory leaks all over the place. See also my talk referenced on this link: wiert.wordpress.com/2009/10/19/… – Jeroen Wiert Pluimers Jan 19 '10 at 11:13
    
Yes, I see why this might be regarded as a problem, and this is exactly what I've read in that article, now that I remember it. However, as I said in my comment to Mason's answer, I don't think this is actually a limitation, as I think you can do it if you implement just a little garbage collection (which won't have any side-effects). – Cloud737 Jan 19 '10 at 15:38
    
If intefaces would have operators, then a whole lot of problems would arise, like for example not being able to cancel out some operators. For example, imagine having an Implicit operator in an interface and then having an object that does need the interface but absolutely not the Implicit operator as well. When you try an assignment, all hell might break loose, and it'd be hard to find your problem. Thing is, operators should never be inherited, if you want to use the "inherited" version you should overload it again and then typecast. But that means classes have to have it, too. – Cloud737 Jan 19 '10 at 15:41
    
As for managed classes, aren't that what records kinda are? Granted, they don't have inheritance and all the other features which truly define OOP, but they could. – Cloud737 Jan 19 '10 at 15:42
1  
Yeah, you could implement operator overloads as an interface, but that leads to problems of its own. Once you take a TInterfacedObject and set its interface reference count to 1, it's no longer safe to treat it as a normal object, because it'll die as soon as the last interface reference to it disappears. – Mason Wheeler Jan 19 '10 at 15:57

3 Answers 3

up vote 9 down vote accepted

Close. It's because objects are reference types and the memory is managed manually. So if you said myResult := myObject1 + myObject2 + myObject3;, you'd have to create an intermediate object somewhere in there, and there's no code to free it, so you get memory leaks.

share|improve this answer
    
Compilers can add the code to manage strings, so why can't it handle the hidden object? I don't think this is the reason. – mj2008 Jan 19 '10 at 8:49
    
@mj2008: For one thing strings don't, and cannot, have custom constructors. The intermediate objects in this case could well be invalid if not instantiated with an appropriate constructor with appropriate parameters that the compile may not always/ever be able to determine. The limitations that would have to be imposed on classes to support operator overloading would I suspect outweigh the benefit. And since you can now have "records with methods", you can use operator overloading in conjunction with those if you wish. – Deltics Jan 19 '10 at 10:44
    
I see why at first glance it wouldn't work. However, couldn't the compiler automatically destroy the intermediary objects except for the last one in this case, and then treat the assignment as normal? For example, first create myIntermediaryObject1 as the result of (myObject1 + myObject2), then add it with myObject3 creating myIntermediaryObject2, automatically destroying myIntermediaryObject1 and the doing the assignment as usual? After all, it's the programmer's resposibility to care for de-allocating myResult if necessary, and the compiler can take care of the rest of the temporary objects. – Cloud737 Jan 19 '10 at 15:31
    
The problem with "records with methods", btw, is that records don't have some OOP features like inheritance (which basically also cancels out polymorphism, virtual methods, and all other things that make us use classes instead, even when not necessary). – Cloud737 Jan 19 '10 at 15:34
2  
The reason the compiler can't destroy the intermediary objects is that it has no way of knowing whether there's any "intermediary" object at all. The operator might return an instance of some cached object from a previous long calculation, or it might return one of the operand objects, or it might return something that needs to keep on existing beyond the current expression, such as an object representing an AST that's going to be evaluated later in the program. The compiler has no idea where the object came from or what you'll use it for later. – Rob Kennedy Jan 19 '10 at 20:05
up vote 1 down vote

You can have operator overloading for classes, but only for the NextGen compiler where classes use ARC.
See: http://blog.marcocantu.com/blog/class_operators_delphi.html

This was introduced in XE5, see: List of Delphi language features and version in which they were introduced/deprecated

share|improve this answer
up vote 0 down vote

Mason Wheeler says that it's impossible because intermediate object management.

But according to Embarcadero documentation, class operators where possible with Delphi 2009.

RAD Studio 2009 - Operator Overloading New Delphi language features since Delphi 7

share|improve this answer
    
Operator overloading are for records. Records are value types while classes are reference types. The documentation in your links are wrong (although they state that this feature is for records, but fail by using classes in examples). See XE3 Operator Overloading. – LU RD Mar 19 '13 at 18:02
    
It's only allowed in records, not classes. But now with XE the records can have methods and properties. So... – EASI Jul 27 '13 at 14:04
1  
@All The docs are the way they are because the .net compiler supported op overloading over classes. Possible because of GC. – David Heffernan Mar 20 '14 at 19:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.