There are a few TNonRefCountInterfacedObject (or maybe better named TNonReferenceCountedInterfacedObject) implementations around (see list of links below).
They can be used to expose interfaces, but do not provide interface reference counting. This means you have to do your own lifetime management, which can bring quite a few headaches.
So each class you descend from it must have proper motivation on why, and how lifetime management is performed.
One thing you can do is mark the class with a hint directive like [WayBack] library.
In addition, [Archive.is] TNonRefCountInterfacedObject / [Archive.is] TNonReferenceCountedInterfacedObject implementations should at least implement [WayBack] IInterface (or [WayBack] IUnknown in really old Delphi versions); I have seen implementations that don’t but just provide almost empty [WayBack] QueryInterface, [WayBack] _AddRef and [WayBack] _Release methods).
Some examples via “TNonRefCountInterfacedObject” – Google Search:
Delphi RTL/VLC/FMX
I used this GExperts Grep Search expression to find the entries below: (_AddRef|_Release|QueryInterface)
Delphi itself has a few implementations of non-standard interface management that have good documentation on their use cases. So take a look at at least these before doing something odd with interface implementations yourself:
- [WayBack]
TAggregatedObject in System
- This redirects all
IInterface implementations to a controller
- It does not implement
IInterface itself, so a descendent must add the interface reference
- Descendants are
TContainedObject and TPropertyPageImpl (the latter used by TActiveXPropertyPage)
- [WayBack]
TContainedObject in System
- This redirects all
IInterface implementations except QueryInterface to a controller
- Descendants are for instance
TSOAPHeaders (via TSOAPHeadersBase) used by TSoapPascalInvoker, TInvokableClass and TRIO, and TConnectionPoint used by TConnectionPoints
- [WayBack]
TInterfacedPersistent in System.Classes
- This supports the notion of (potentially) being owned by another
TPersistent. Classes like TCollectionItem, TFieldOptions and TEditButton implement this ownership behaviour.
- When owned, then redirect reference counting to the owner (if that owner implements
IInterface), but not QueryInterface
- When not owned, then it is effectively non-reference counted
- [WayBack]
TComponent in System.Classes
- This supports the notion of (potentially) being owned by another
TComponent. Classes like TComponent and TCollectionItem implement this ownership behaviour.
- When owned, then redirects all
IInterface calls to the owner (including QueryInterface).
- [Archive.is]
TXPEditReaderStream in DUnit XP_OTAEditorUtils. It is largely undocumented.
TXPInterfacedObject in DUnit XPInterfacedObject. It is largely undocumented too.
Not so good examples:
- [WayBack]
TCustomVariantType in System.Variants (which is basically TSingletonImplementation with a lot of extra methods)
- [WayBack]
TSingletonImplementation in System.Generics.Defaults(which is basically what most TNonRefCountInterfacedObject implementations do; this is sort of OK as it is meant to be used only in [WayBack] TCustomComparer<T> and descendants that are supposed to be singletons).
IUnknown in Winapi.Ole2 (this whole unit is undocumented; the class only has virtual abstract methods; the unit – together with Winapi.OleCtl – seems to be only meant to support the depcrecated Vcl.OleAuto unit.)
And of course there is the standard implementation with proper multi-threading support:
There are quite a few classes that implement reference counting while descending from things like TComponent, usually without the proper multi-threading support that TInferfacedObject has:
Read the rest of this entry »
Like this:
Like Loading...
The Wiert Corner - irregular stream of stuff 