Why isn't operator overloading available for classes in Delphi?

views:

204

answers:

+8 Q:

Why isn't operator overloading available for classes in Delphi?

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

+9 A:

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.

Mason Wheeler 2010-01-19 01:29:53

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 2010-01-19 08:49:34

@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 2010-01-19 10:44:33

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 2010-01-19 15:31:55

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 2010-01-19 15:34:51

Btw, the Intermediary objects I'm talking about in this case would be constructed in the overloaded operator method, so no need for the compiler to know which constructor to call, just to know for what objects to call the destructor.Also, myIntermediaryObject2 is the only one not getting destroyed, and it will be the new object myResult will point to, just like in a normal assignment (and the programmer should expect the pointer to the heap object to change like in a normal scenario as well, so I don't see a problem here with manual de-allocation).

Cloud737 2010-01-19 15:44:30

The compiler can't destroy the intermediate objects for because the Delphi objects has no default destructors.

Serg 2010-01-19 16:40:00

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 2010-01-19 20:05:50

Ok, that's clear enough for me. :D Thanks for all the details and having patience with me.

Cloud737 2010-01-19 22:17:16

ansaurus

tags:

views:

answers:

Why isn't operator overloading available for classes in Delphi?

related questions