I'm tick at times - ptr confusion

Hello all, I'm new to all this, but i'm intrigued by OO programming as an idea, so ive plumped for the blitzmax pc beta, and am on the whole having great fun learning about how it all works.

I work in the games industry for my job, but im an artist (stop booing please) and this is quite an adventure for me, and a rewarding one at that.

but..

i have a bunch of objects set up with methods etc. galore and my naff asteroids clone was coming along nicely, but my poorly designed interfaces etc. have made things begin to fray around the edges and go a bit* spaghetti-like.

* meaning very very.

I'm especially foxed about the Ptr command, and Varptr, and Var for that matter.

I think i understand that Var in a function argument definition means pass by reference rather than value.

I always get my head in a twist when trying to implement pointers to objects as fields in objects i have made. Perhaps this is the wrong way to do it? Any advice happily accepted.

I'm going to get some OO theory books from the library and see if they can help, but any directly blitzmax compliant assistance with using pointers to reference instances of types would help my accumulating grey hairs massively.

(pesky long winded sentence)
to summarise: im stuck with how pointers work with objects in blitzmax. Also any help with the most sensible principles designing interrelated objects which are to 'own' each other and stuff would be great.

cheers from a budding thickie!

Welcome to the forums :)

Well, types are always passed by reference - a type variable is a pointer. You don't have to do anything special to make the field in another type point to a type. For example:

Type PointsAtAnother
 Field pointer:TheObject
End Type

Type TheObject
 Field Dat$
End Type

Local A:PointsAtAnother=New PointsAtAnother, B:TheObject=New TheObject

A.pointer=B
B.dat="hi!"
Print A.pointer.dat
B.dat="See, it works!"
Print A.pointer.dat

thanks for the info - custom types always passed by reference you say - eexcellent. :)

i was worried about some infinite recursive dependency of death happening if I wasn't careful. :)

something has just clicked actually, and i thank you for the help.

is there any problem with having 2 objects which reference each other in their fields? apart from sounding like ropey design in the first place?

anyhoo - cheers muchly for the help. rubbish asteroids clone coming up shortly :D

Welcome :)

There shouldn't be too much trouble with having objects reference each other. The only problem I can see is with the automated memory management. Because one object sustains the other, and the other sustains it, the only way to kill them is to set their pointers to 0. So, if you lose references to both objects, they'll just sit there without being deleted. Its not too much of a problem. I believe the builtin TList type does this in a big long chain. each link has access to the previous and the next link, and when deleted it goes through all its links and nulls them out. Check the Advanced Topics in the Language Reference.