Why does Assigned return true for uninitialized variables?

Question

I read many posts on forum about pointers, Assigned function, Free function, FreeAndNil function, etc... I already know Free function

Answer 1

From the documentation of the Assigned function (emphasis mine):

Use Assigned to determine whether the pointer or procedure referenced by P is nil. P must be a variable reference of a pointer or procedural type. Assigned(P) corresponds to the test P<> nil for a pointer variable, and @P <> nil for a procedural variable.

Assigned returns false if P is nil, true otherwise.

Note: Assigned can't detect a dangling pointer--that is, one that isn't nil but no longer points to valid data. For example, in the code example for Assigned, Assigned won't detect the fact that P isn't valid.

The Assigned function is effectively implemented as:

function Assigned(const P): Boolean;
begin
  Result := Pointer(P) <> nil;
end;

So the function isn't really checking whether the value truly is assigned. Rather it's checking a side-effect of being assigned.

• As a result the function is guaranteed to return True if it is assigned.
• But behaviour is undefined if the value is uninitialised. Basically since an uninitialised value has a garbage value left over from previous operations, it might be nil, or if might not.

Another thing to note is that Assigned has no way to determine the validity of its value. E.g. The following call to Assigned returns True even though the underlying object is no longer valid.

var
  LObject: TObject;
begin
  LObject := TObject.Create;
  LObject.Free;
  if Assigned(LObject) then ShowMessage('Still assigned!?');
end;

---

EDIT: Addendum

In response to the second part of your question.

Is there any safe way to know if a class variable already has its create method executed?

There is no safe way to determine if an object instance has been created. (There's also no way to reliably confirm that it hasn't already been destroyed.)

However, there are conventions (and good practices) you can follow to help you on the way.

First note that you should only be "unsure" if something was created if it's a deliberate feature of that piece of code. E.g. If you intend an object to be "lazy initialised".

• What I'm trying to say here is: Never check Assigned just because you're worried that there might be a bug that prevents it from being assigned.
• Not only is this impossible to do reliably, but you overcomplicate your code... Which increases the chance of bugs.
• Also if you find something is unexpectedly not Assigned, then what can you do about it? Ignoring it would simply be pointless. Also, it's no good saying: "Ok, then I'll create the object". Because then you're duplicating creation logic in multiple places.
• Basically you should try to make every part of your program correct - not have your program try to double-check itself everywhere.

So now that we're (hopefully) agreed that you only check if something is created if you've deliberately chosen that being created is optional. You do this as follows:

• At first opportunity, ensure the variable/field reference is initialised to nil. So then it's guranteed to be assigned a value which means the object is not created. (Yes, the naming is a bit warped.)
• You can set the vairable/field reference to a new instance of an object or set it by copying another reference of an already existing object. (Note the existing refernce might also be nil, but that doesn't cause any problems.)
• If you ever destroy the object (or even just want to stop using it from that reference), set your variable/field reference to nil again.
• NOTE: Delphi already initialises the member fields of a new class. So those won't need special attention.