TRttiContext.Create() & TRttiContext.Free()

I thought I needed to take a break from the normal articles to explain why I call
TRttiContext.Create() and TRttiContext.Free() when in fact you don't need too.

Yes you don't need to do it, but yet I do... Why?

First off lets look at the implementation of both.

class function TRttiContext.Create: TRttiContext;
begin
 Result.FContextToken := nil;
end;

procedure TRttiContext.Free;
begin
 FContextToken := nil;
end;

At first glance there is nothing special, FContextToken is set to NIL in both cases.

So what does setting FContextToken to NIL really do?

We all know that Delphi currently does not have any Garbage collection mechanism. As such having a rich RTTI library that is based on Objects could be problematic.

In my code an I able to such cool things as...

c.GetType().GetField().FieldType.ToString

Without having to set temporary values for each returned object, to free them.
How is this possible without a garbage collector?

Well under the hood you will find TRttiPool that contains all of the RTTI object that are created.
When this pool is freed all of the objects created during RTTI calls are then freed.

The construction and destruction of this pool is controlled by TPoolToken which is the Interface that is stored in FContextToken.

When the TPoolToken is created and freed, the PoolRefCount is maintained, when it reaches zero the TRttiPool is freed.

So why call .Create() and .Free()

So lets start with .Create()

So it's not like calling this code is a huge overhead, yes sure a record is managed and as such it will be initialized, making the call to set FContextToken redundant. well sort of... Although I don't intend every create a pointer to TRttiContext, its possible have the memory space not be initialized as expected, unless you are calling .Create.

I also can't be sure that the implementation will remain as simple. It is very possible that additional code could be called at this point. Keeping my code safe in the future is always critical to me in my designs.

Moving on to .Free()

Well, I like to keep my memory foot print clean. Sure when the TRttiContext variable goes out of scope the exact same behavior will occur.

Very early on when playing with new RTTI I inadvertently caused an access violation in a TCustomAttribute Descendant destructor. With the call to .free() it was easier to see what had caused the problem. Instead of having it occur after the destruction of the Object that had the TRttiContext declared as a field.

And just to stop the obvious comment.... Yes, I know the documentation say's you don't have to call .Free() And implies that the technique is important because it insures that all RTTI Objects are cached and reused, well this would only be true of TRttiContext was declared as a global variable, which I think is a very BAD idea.

Instead I think you should keep your TRttiContext around as long as you need it, but free it when the time is correct.

In short... I find it a matter of personal preference.