Delphi style of TInterfacedObject memory management forever?
Delphi style of TInterfacedObject memory management forever?
Hi. I know nearly all of you are aware of the differences in memory management when working with objects and with interfaces. But IMO the Delphi style is violating the concepts that the user of an object has not to know about internals of an object. The following small examples shows a typical trap ... there are a lot others.
var
oMy: TMyObject; // class(TInterfacedObject,IMyInterface)
iMy: IMyInterface;
begin
oMy:= TMyObject.Create;
try
Assert(oMy.RefCount=0);
finally
oMy.Free;
end;
// but
oMy:= TMyObject.Create;
try
iMy:= oMy; // I get access to the implemented interface
Assert(oMy.RefCount=1);
finally
oMy.Free; // crashes
end;
end;
I know that some developers with argue to "only use interfaces and not the objects itself". But a modern programming language should not be that sensitive.
Now to my actual question: will ARC solve that problem and the code above would not crash? Or do we have to live forever with this nasty traps?
Hi. I know nearly all of you are aware of the differences in memory management when working with objects and with interfaces. But IMO the Delphi style is violating the concepts that the user of an object has not to know about internals of an object. The following small examples shows a typical trap ... there are a lot others.
var
oMy: TMyObject; // class(TInterfacedObject,IMyInterface)
iMy: IMyInterface;
begin
oMy:= TMyObject.Create;
try
Assert(oMy.RefCount=0);
finally
oMy.Free;
end;
// but
oMy:= TMyObject.Create;
try
iMy:= oMy; // I get access to the implemented interface
Assert(oMy.RefCount=1);
finally
oMy.Free; // crashes
end;
end;
I know that some developers with argue to "only use interfaces and not the objects itself". But a modern programming language should not be that sensitive.
Now to my actual question: will ARC solve that problem and the code above would not crash? Or do we have to live forever with this nasty traps?
+Agustin Ortu "There is nothing wrong with Delphi memory model, either manual memory management, ownership based or pseudo ARC or whatever you like to call it"
ReplyDeleteManual memory management is old. I once read a document for a software library that said, "And we've even included a C API for those who believe the state of the art in computer science culminated with the invention of the pointer." :-)
Manual memory management is extra mental overhead that isn't needed for the desktop applications that Delphi was intended for. It's just more potential for bugs and violates the whole idea of Rapid Application Development.
An article I was just reading this morning about improving developer productivity began "1.Don't waste time doing the compiler's job.
When developer brains do what computer brains can do much better then that's usually a costly mistake. " Manual memory management, like hand-written assembler, is wasting human time doing what the computer can faster and better. A human should be spending their time thinking about the high-level issues relating to solving the problem they're writing the code for, not worrying about low-level algorithmic details or performing housekeeping tasks.
Similarly, the whole "record with methods" thing was an attempt to bolt on features without changing the nightmare code base of the ancient desktop compiler or break anything. They wanted operator overloading but didn't want to change the memory management of classes, so they changed records - but records don't have inheritance. Now you have one structure that has inheritance but no operator overloading, and one with overloading but no inheritance. Obviously if you were starting from scratch you'd simply roll that all into classes; there's no logical reason to have both if you were starting clean.
There are many other areas in the language where you find things that either were bolted on, or are long outdated but still lingering around for compatibility reasons. How many ways are there to open a file now? Five? This is the kind of thing that haunts Java today - they actually have a flowchart in the [Java] documentation now to help you choose how to open a file! :-(
Joseph Mitzen Delphi allows the developer to manage the memory the way he wants, similar to C++ which also has manual management but can leverage to smart pointers or garbage collector if wanted.
ReplyDeleteObviously critical systems may need different memory management approaches; Delphi doesn't impose anything on you, it's quite flexible: wanna use ARC? Sure go ahead, it brings overheads and some rules and caveats you must follow. Wanna manage the memory yourself? Go ahead. You like RAD ownership based memory management? Go ahead
Agustin Ortu"Delphi allows the developer to manage the memory the way he wants ."
ReplyDeleteWe don't have options on the desktop platforms right now.
"Obviously critical systems may need different memory management approaches;
Delphi doesn't impose anything on you, it's quite flexible: wanna use ARC? Sure go ahead"
On the desktop?
It's a debatable point, but some feel that in language design too much choice leads to great complexity. This is often a charge directed at C++, suggesting they've added every feature imaginable and made the language much harder to learn as a result.
Delphi isn't a systems programming language and was never marketed that way. It was originally aimed at those writing grid-oriented front ends to client-server databases. Now it's being marketed as a cross-platform application tool. I'm not sure that Delphi needs low-level memory management for its intended uses.
Apple was able to maintain backwards compatibility for Objective-C libraries while designing a new language from scratch that incorporated modern language features and design standards (Swift). When CodeGear was formed, Nick Hodges put out a blog post talking about the many legacy features left in Delphi, some dating back to Turbo Pascal, and how they wanted to have a compatibility mode for legacy code but a "modern" mode that would introduce compatibility-breaking new features for those writing new code. Sadly, that never happened, but might be the only solution to resolve the tension between the two Delphi camps who are either primarily maintaining old code or are writing new code. I remember Marco talking about how writing a new desktop compiler (something else that sadly never happened) would give the developers a chance to get rid of the "cruft" and how one wouldn't insist the new VW Beetle work with original Beetle parts and accessories.