Check if object is created

[T-Bear]

Hi.
I am having a little problem with my code.

So i have an object (TObject).

Then i have a Pointer type to that object (PObject = ^TObject)

In my code i use a pointer variable
MyVar: PObject;

Now my question is: How can i check if MyVar has been created? I have tried assigned(MyVar) but the code was not executed when the object should have been created. I also tried "If MyVar^ <> NIL Then", but same result. I either get a SIGSEGV error, or the code is never executed.

Is there anything i have missed?
Thanks for help!

[User137]

Assigned and nil checks are propably only thing you have. You expressed your question so vaguely we can't tell if there is some sort of error about it you are making.

By the way, object instance of a class is already behaving like a pointer, so you should always use TMyObject instead of PMyObject. Making a pointer about it actually might cause problems with inheritance... i don't know. Just, having a pointer to pointer is ... pointless (often times)

[T-Bear]

I found out that it was me doing something wrong, and it works now. Still thanks for your help.

By the way, object instance of a class is already behaving like a pointer

So i can do something like this:
var
Object: TObject;
ObjectPtr: TObject;

begin
Object:= TObject.Create;
ObjectPtr:= @Object;
end.

Im just wondering caus i need that kind of functionality, which is why i am using pointers in the first place.

[User137]

You never do this:

TObject.Create;

TObject is an abstract class, basically useless as is. You inherit from TObject when create another class, which is why i always use TMyObject as example. It means:

type
  TMyObject = class(TObject)
  // or same as
  TMyObject = class

We can do:

type
  TMyObject = class
  public
    n: integer;
  end;
...

var a, b: TMyObject;
begin
  a:=TMyObject.Create;
  b:=a;
  a.n:=10;
  // At this point a.n, and b.n both would tell you 10

  // Lets go freeing then...
  FreeAndNil(b);
  
  a.n:=20; // Crash
  // Should just set a nil, because it refers to same object
  a:=nil;
  // FreeAndNil(a); // This is propably legit alternative, but i would not do .Free second time
end;

[pitfiend]

From my experience I can tell that pointers, unless other variables types, are never initialized, you must do it by hand in code. Also, any further operation without proper assigment will lead into troubles as the compiler never check in advance, you are at your own. As noted by User137, it's meaningless to have pointers to objects as they are pointers themself, having extra pointer variables can lead into leaks or access violation if not handled properly, you must be aware that making your code more complex by using that render your maintenance harder if not documented.

[SilverWarior]

I found out that it was me doing something wrong, and it works now. Still thanks for your help.

So i can do something like this:
var
Object: TObject;
ObjectPtr: TObject;

begin
Object:= TObject.Create;
ObjectPtr:= @Object;
end.

Im just wondering caus i need that kind of functionality, which is why i am using pointers in the first place.

What kind of functionality are you talking about? What are you trying to achieve?
If you use your Objects to store data for some ingame entities and you have fixed number of them you can simply use:

var Entity1: TMyObject;
Entity2: TMyObject;
.....

Entity1 := TMyObject.Create;
Entity2 := TMyObject.Create;

...

But if you have dynamic number of entities in your game go and use TObjectList to store them like so:

var Entity: TMyObject;
    Entities: TObjectList;

//If you use TObjectList.Create(True) ObjectList then Owns the objects you added to it. 
//This means that when you will remove one of such objects from ObjectList it will automaticly
//call objects destructor method and thus destroy the object. This will hapen even when you call 
//ObjectList.Free to destroy the object list. So it can be useful for quickly destroying all ingame entities.
Entities := TObjectList.Create(False);

for N := 0 to 99 do
begin
    Entity := TMyObject.Create;
    Entities.Add(Entity);
end;

So basically ObjectList contains pointer to all the object you added to it and you can acces them with:

//TMyObject is used to tell program which calss structure are you planning to use
//Entities[I] returns you Pointer to the object which is stored in ObjectList at index I
TMyObject(Entities[I]).SomeValue

Even better you could make deriverate class of TObjectList so that it works with TMyObject class insted of TObject one. This will alow you to acces objects stored in TObject list by simply caling: Entities[I].SomeValue.

NOTE: The code exapmles were writen directly from my head so there might be some Typos in it.


Anywhay if you give me more information of what are you trying to do I can write you actual code that you can use.

[Super Vegeta]

Am I the only person around here, who finds the it-is-a-pointer-but-not-exactly behaviour of classes confusing and uses objects instead?

[LP]

Am I the only person around here, who finds the it-is-a-pointer-but-not-exactly behaviour of classes confusing and uses objects instead?

If you are referring to using legacy "objects" (e.g. type TTest = object), then I would expect this functionality to be removed eventually (as far as I understand, it has been considered deprecated for quite some time now), at least in Delphi.

So i can do something like this:
var
Object: TObject;
ObjectPtr: TObject;

begin
Object:= TObject.Create;
ObjectPtr:= @Object;
end.

Im just wondering caus i need that kind of functionality, which is why i am using pointers in the first place.

Well, not exactly:

type
 TMyClass = class // TObject is assumed as base class
 end;
var
  Object: TMyClass;
  ObjectPtr: TMyClass;

begin
 Object:= TMyClass.Create();
 ObjectPtr:= Object; // now ObjectPtr has reference to Object

 Object.Free; // now Object no longer exists, ObjectPtr contains invalid reference.
end.

[Super Vegeta]

If you are referring to using legacy "objects" (e.g. type TTest = object) (...) as far as I understand, it has been considered deprecated for quite some time now

Oh damn. Seems I somehow instinctively like the old things more.