"RokuMarkn" wrote:( I moved it here as it really is another topic. from, here)
The ref count is the number of variables referring to the object. It's set to 1 when you do CreateObject, and it get incremented every time a new variable is set to refer to that object, and decremented every time any such variable is modified or destroyed.
In answer to another one of your questions, all local variables are destroyed when the containing function exits. There is no need to set a variable to invalid unless it's going to remain in scope.
Also, I've updated section 4.3 of the Brightscript Language Reference to explain a bit more about references and such. I'd appreciate any feedback if it isn't clear.
scr = GetGlobalAA().scrSo, a local variable that is "another" reference to the original <roScreen>, yes?
scr = GetGlobalAA().scr
do some stuff
for each obj in objList
Part of the confusion is that they are local variables. If the function has returned then in my mind the local variable should have disappeared and along with it the reference count it held.
"dev42" wrote:You'll do well to link also where did you move it from. Not everyone (me in particular) reads every thread or in particular order.
( I moved it here as it really is another topic. )
Capitals "issue"(?)/ possible confusion: doesn't Java designate lower case as intrinsic and first letter Capital as Object? Furthermore, you weren't consistent and used "integer" further down. Yes, BrightScript is BrightScript and can/should have its own conventions. ( Sorry if nitpicking, but trying to err on helpful. ) Perhaps expand, "An object type is one of Array, Associative Array or Brightscript Component." to include more BrightScript correct code? ie roArray, roAssociativeArray? Or is there an instrinsic "Array" type too?BrightScript is a case-insensitive language, so capitalization is a matter of style (or lack thereof). Java is a completely different can of worms.
BrightScript is a case-insensitive language, so capitalization is a matter of style (or lack thereof). Java is a completely different can of worms.
roArray and roAssociativeArray are BS components ...
FWIW, I'm learning *more* and have just discovered that I can step thru code in the debugger... so I *should* be able to insert multiple STOP's and watch the change of the refcnt, yes? !!!
push: function(x): m.stk[m.ptr] = x: m.ptr = m.ptr + 1: end function,
pull: function(): m.ptr = m.ptr - 1: return m.stk[m.ptr]: end function
' the following is in main()
s = stack(100)
for i = 1 to 10: s.push( createObject("roScreen") ): end for
for i = 1 to 10: screen = s.pull(): end for
screen = invalid
' at this point all roScreens should be closed, right? wrong!
Probably. But don't obsess about reference counts, just have faith that it works "like magic" and in most cases you have nothing to worry about, the system takes care of objects lifetime and disposal.
Avoid using globals (GetGlobalAA()) when you can pass something as argument and you should be fine, since leaving out of nested functions will be cleaning behind.
For edu-tainment's sake, i made here an artificial example to demonstrate how one "memory leak" happens:<see above>
So i got a factory function Stack(n) that constructs a stack with N elements and 2 methods, `push` and `pull` that respectively add and remove elements. Then i shove 10 roScreens on that stack, then i take them back and even invalidate the last one. And yet, they are not all gone. How come? - figuring that out will be a good exercise.