Beware the GC

BlitzMax Forums/BlitzMax Bug Reports/Beware the GC

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

Vlad, I disagree. This is a bug with the optimizer in the Blitz compiler. An object shouldn't be GCed after the last use, but instead after the object loses scope. In the case of Local objects in the main program, that'll be at program exit.

The above example demonstrates why. The GC cannot anticipate all the different ways that an object will be referenced from a program. What about Var and Ptr? Or passing the object to a .dll?

It is also possible for custom types to be accessed similarly to the TLink example above. Create a SpriteGroup type and within a list of Sprite types. You decide you want to manipulate the sprites directly instead of the entire group at once. The SpriteGroup as well as all the sprites get GCed because SpriteGroup is no longer being referenced in your program.

Take a look at this example. Debug mode prints all 50s, release prints all 0s
SuperStrict


Type TAlpha
	Field Array:Int[]
	
	Method New()
		Array = New Int[100]
		For Local i:Int = 0 To 99
			Array[i] = 50
		Next
	End Method
	
	Method Delete()
		For Local i:Int = 0 To 99
			Array[i] = 0
		Next
	End Method
End Type

Local Alpha:TAlpha = New TAlpha

Local Array:Int[] = Alpha.Array
Local s:String

For Local i:Int = 0 To 10000
	s = ""
	For Local j:Int = 0 To 99
		s :+ Array[j]+" "
	Next
	Print s
Next


I think it is very reasonable for a programmer to expect that an object will be valid and components can be accessed throughout it's entire scope, not just until the main object is no longer used.