I have an array of class instances. The number of elements is unknown at compile time (they are read in from a file), so I am populating the array with the Append method. It appears that an array of objects is actually an array of pointers to the objects. I do not understand the scope issues.
If I declare a single instance of the object outside of a loop, then inside a loop read the properties into the instance, and append the instance to the array, all the array elements have identical property values - they are all pointing to the same instance.
// of Object is a class
Dim c As New Object
Dim a() as Object
results in an array with correct unique elements. This works, but I am concerned that it works by accident. All of the instances have the same name, and maybe go out of scope when the For loop (or method) is finished? I am confused as to why this would work, given that the former example fails. Also in my application, the array is a global property of the window or app. I do not understand the scope and pointer issues here. Is this reliable, or is there a better (more reliable) way to accomplish this?
Edit: interesting that in the preview window there are tabs in my code but in the posting, not.
The second method works because c becomes a new object then a(x) gets a reference to that object so now you have two pointers to the same object. On the next iteration c becomes a new object while a(x) still keeps the reference to the original and therefore the original object is not destroyed.
Objects lifespan is controlled by [quote=302524:@Jon Fitch]It appears that an array of objects is actually an array of pointers to the objects[/quote]
this is a correct statement
if your create an object
a=new myObject
and then do
b=a
a and b are THE SAME OBJECT, if you change “A” then “B” changes and vice versa
The objects live for as long as SOMETHING points to them. [ARC = automatic reference counting]
If the variables “A” and “B” go out of scope, the object vanishes. but if A goes out of scope, and B does not, the object remains
this is unlike normal scalar variables
a=5
b=a // b is a COPY of a, and can be changed without affecting "a"
Ok, together, those answered my question. I was aware of the referenced nature of objects, but unaware of the ARC idea. So in my second example, c does go out of scope, but due to the reference to it, the object is maintained until that reference no longer exists (which is a compile time decision?).
What if there are discrete instances:
[code]Dim a, b As myObject
New a As myObject
new b As myObject
a = b[/code]
Did the New create a unique instance, or does the compiler optimize that out and I have only one with two references?
New DOES create a new instance… HOWEVER, when you then do A=B, the new instance is B vanishes, and B becomes a pointer to the same object as A
If you want a COPY (independent objects that at inception contain identical information), then you need to create a CLONE method
CLASS myobject
dim prop as integer = 5
END CLASS
dim a as new myobject // a is an instance of myobject with a value of 5
dim b as new myobject // b is ANOTHER instance
a.prop=10
// at this point A.prop is 10, and b.prop is still 5 (it was its own instance remember? :) )
b = a
// NOW b.prop is pointing to the same object as A, so BOTH have 10 as a value
b.prop = 19
// BOTH a and b are 19 (same object, yeah?)
a simple clone method
CLASS myobject
dim prop as integer = 5
function CLONE as myobject // yes the function can return an instance of it self.
dim temp as new myobject
temp.prop=prop
return temp
end function
END CLASS
dim a as new myobject // a is an instance of myobject with a value of 5
dim b as new myobject // b is ANOTHER instance
a.prop = 10
// a=10, b=5
b=a.clone
// now B=10, but it can be changed, but it does NOT point to the same object as A
Like saying “me” and “myself” - two unique ways to refer to the same thing using a different “word”
In Xojo thats “a” and “b” that both refer to the same actual object - but a & b are UNIQUE references to that object
No, it’s a runtime decision. Objects are reference-counted. Once the count of references falls to zero, the object is immediately destroyed.
dim a as object
dim b as object
a = new object // an object is created with count=1
b = a // the object's count is increased to count=2
b = nil // the object's count is now count=1
a = nil // the object's count is count=0 and it is immediately destroyed before the next line of code executes
[quote=302542:@Tim Hare]No, it’s a runtime decision. Objects are reference-counted. Once the count of references falls to zero, the object is immediately destroyed.
[/quote]
That all seems consistent then. The two instances in my example exist separately, up until the moment one is assigned to the other, at which time the reference count to ‘the one’ falls to zero, and that instance (as a unique memory location) is destroyed and it becomes merely a reference to ‘the other’.