Which class memory management model would you prefer for Delphi?
Posted by jpluimers on 2018/01/31
An interesting discussion on ARC and classic memory management in Delphi and ideas on hybrid ways: [WayBack] Which class memory management model would you prefer for Delphi? Or better, which one would fit better for your needs? – Malcon X Portela – Google+
–jeroen
The Wiert Corner - irregular stream of stuff 
Steven Kamradt said
Maybe I’m just stuck in my ways, but I see nothing wrong with the traditional way class memory management has been performed since Delphi 1. Changing it will break quite a bit of code, and for what? so you don’t have to .free your object when your done with it? There are existing patterns that allow you to wrap your creates in such a way to get this behavior today, if your one to want that. Or am I missing the point of ARC?
jpluimers said
The main thing with manual memory management in any environment is to keep lifetime of memory referenced long enough so it is not freed unless all referenced have become invalid, while still freeing up that memory soon enough to keep memory usage bound.
I don’t think the objective of a class memory management model should be to break things. Such a model would be plain wrong. Memory management through interface references did not break things. Any future memory management model should not break anything either.
ARC is similar to interface based memory management but instead of manual reference counting that the RTL does for interfaces, it is automatic by the underlying platform.
ARC is part of clang which is the mobile side of Delphi needs to be compatible for interoperability with iOS, but I’m not sure for Android (they might have just kept it there for consistency within the mobile support).
KMorwath said
Depends on what you use Delphi for. If you just mostly write database front-end apps, you’ll like an automatic management. If you write more complex code which needs to perform also specific memory management functions, you’ll need a manual system witch low level memory access also.
Delphi needs to decide what kind of tools wants to be. A simple front-end generator, or an all-round tool able to deliver highly complex applications. For a long time it’s aiming at the former, although being capable of the latter.
It also needs to justify its price, especially now they removed upgrades.
rvelthuis said
You can also have low level memory access with ARC. I don’t quite understand why people think you can’t. ARC is not the same as a managed system like Java or C#.
jpluimers said
With Java and C# you can also have low level memory access.
KMorwath said
For “low level” I mean being able to avoid any “magic” and being in full control of how memory is managed, and avoid silly indirection like smart pointers.
There’s a reason why still today C is preferred to C++ – and why Java and C# are utterly useless for some kind of applications.
It’s exactly the question: should Delphi be a C/C++ competitor, or Java/C# one? While in the beginning it was the former, it became the latter. Just against Java and C# it will lose almost always – even with ARC.
Trying to chase C# was the biggest mistake Borland did. Today you select a native-compiled language if you have specific needs which cannot be addressed by p-code languages running in a VM.
There are also new languages like Rust demonstrating you can create languages that are C/C++ competitors – and Delphi lost a lot of ground when it could have delivered C/C++ like features without the complexity and in a safer way.
HeartWare said
Link doesn’t work (404).
HeartWare said
The [WayBack] link works – the “long” one doesn’t.
jpluimers said
That’s why I started to save web-content on the WayBack machine a while ago: original content often disappears.