Delphi XE3 is preparing (weak) reference counting for class instances
In Delphi, you have several ways of handling data life time, therefore several ways of handling memory:
- For simple value objects (e.g.
byte integer double shortstringand fixed size arrays or
recordcontaining only such types), the value is copied in fixed-size buffers;
- For more complex value objets (e.g.
stringand dynamic arrays or
recordcontaining such types), there is a reference counter handled by each instance, with copy-on-write feature and compiler-generated reference counting at code scope level (with hidden
- For most
classinstances (e.g. deriving from
TObject), you have to
Freeeach instance, and manage its life time by hand - with explicit
TInterfacedObject, you have a
_AddRef _Releasemethods (this is the reference-counted COM model), and you can use Delphi
interfaceto work with such instances - see this blog article.
classlevel are about to be introduced at the compiler and RTL level.
Even if this feature is not finished, and disabled, there are a lot of changes in the Delphi XE3 Run Time Library which sounds like a preparation of such a new feature.
First of all, there is a new compiler conditional, disabled in XE3, which is
See for instance this official XE3 documentation article.
Then, there are some attributes:
[Weak] [UnSafe] [Ref] and
their corresponding types in
WEAKREF conditional sounds associated to those.
And some new low-level functions, which try to implement some weak-reference
system with Zeroing, just like we did for mORMot - and for Delphi
6 and up.
Main implementation difference is that we maintain a per-class hashed list, whereas the XE3 version is global, and obviously not yet profiled for speed (there is a giant lock for the whole application, using
not the best scaling method I know).
The link between compiler and RTL sounds already possible, even if not enabled:
[Weak]references appear in some places in the XE3 code (e.g. in
- Some low-level functions like
FinalizeArray(called not only for arrays) check if type information equals nil for any field, and in this case, handle it as a weak reference (via the new
I was not able to see a difference between a weak reference and a zeroing
weak reference, like what we did for mORMot.
Most of the time, a weak reference is enough. Zeroing weak references are safer, but also much slower, even if you manage a huge number of instances in such a global locked list.
As a quick conclusion, we may say that Embarcadero future for Delphi is to
ARC model used by Apple, including zeroing weak pointers.
It is IMHO a better solution than a garbage-collector based memory model for an unmanaged environment like Delphi.
But one issue of the implementation as previewed from XE3 sources (in
addition to its alpha stage and poor performance) is that it is global to the
TObject memory model will be either
ARC-based or manually handled (just like before).
This is a breaking change in the Delphi way of coding, and I would rather prefer a dedicated
TObject / class type, able to coexist with the
huge amount of third-party source code. Even if most user-level code may work
with no issue (since
Free will use the reference counting), some
lower level code may be broken by such a change.
class type may allow clear distinction between the
"classic" model expecting manual
Free of instances, and the new
ARC model with its own style of coding.
I like very much the FreePascal approach, with its syntax
modes: you can have several syntax and even
in the same application. It is used for instance to mix objective
pascal and classic pascal classes in the same project. Clean and
It will also make the OS X integration much easier than the current interface-based marshalling of the Objective C APIs within Delphi. A lot of plumbing which should be leverage at compiler level.
I hope Embarcadero has such features on the road map, otherwise its future could be problematic: not compatible with legacy code (which is its main strength), and with no obvious benefit when compared to alternatives.
Feedback and comments are welcome on our forum, as usual.