To: Multiple recipients of list DIRECT-L
As far as I know there's not a lingo command that deletes an object.
In C++ it is "delete". Does anybody knows whether the memory occupied
by a big object is freed by simply using the command
"set oVariable = 0" or there's any other similar way to do it?
Thaks in advance.
8-) Bernie (berniecc@hotmail.com)
Simply break all references to the object and it will be deleted. This
means resetting ALL variables that are pointing to it (including any
references in the actorlist etc.), to 0. That will do the trick.
-MikeS
=============== Michael Scaramozzino, mikes@dreamlight.com
A Lingo object is automatically disposed of when there is no longer *any*
references to it. If you need to delete an object, then remove all
references to the object in question. Also don't forget about the actorList
if you have been using it.
Some people delete their references to objects by setting the variable
containing the object to 0.
set gmyGroovyObject = 0
I like to use a variable that has never been initialized. I always call it
gVOID.
set gmyGroovyObject = gVOID
-Ron-
Another solution is to make a do-nothing movie script handler...
on void
end
set gMyGroovyObject = void()
- Glenn M. Picher Dirigo Multimedia gpicher@maine.com
My favorite, because it requires no extra code away from the point of use:
set gMyGroovyObject = value(void)
(... assuming you don't have a variable named void.)
- Mike Edmunds
Macromedia Director Engineering
Actually I'm curious. Is this any better than simply setting it to 0, or is
this more of a personal preference issue?
set gMyGroovyObject = 0
Neither method requires any code away from the point of use, and Director's
loose typing easily allows putting the integer 0 into what used to hold an
object pointer. Both methods result in releasing the object.
> set gMyGroovyObject = value(void)
The main benefit that I could see with the value(void) approach is that it
may be a touch more obvious that you are clearing out a pointer. Does this
approach actually release more memory? The memory used for the variable
itself? Does setting it to void release it from the symbol table or
something similar?
> set gMyGroovyObject = 0
The 0 approach that I usually use in Director is more concise but could be
a touch more confusing if someone was reading another's code and didn't
quite understand the reason for setting it to 0. This obviously will hold
the integer 0 in memory where it is really no longer needed. If the
vaule(void) approach actually removes the variable as well from memory,
then I'd switch to using that method unless the variable is used again
later and reset to point to an object again which would remove and then
recreate the variable.
This brings up some subtle questions that I hadn't really considered
before. I really didn't worry too much about such issues since Lingo is not
strictly typed unlike C++.
When a variable of a certain type such as an object pointer is created in
Lingo it obviously must reserve enough memory to hold such a pointer. Does
subsequently putting an integer or other type of value into the variable
type cast the value to the type of the original variable? Or, does it
create a new variable of the new type (using a different amount of memory
based on the new type)? And does setting it to value(void) actually destroy
the variable itself releasing the variables memory (I'm not talking about
the objects memory, but the memory used by the pointer itself) or simply
set it to some type of null pointer value that does use memory until it
goes out of scope?
Any technical details about how Lingo handles internal variables would be
useful when considering such issues.
Are there any other subtle reasons for leaning one way or the other that I
haven't considered?
-MikeS
For me it's just personal preference. I don't want to get in the habbit of
leaving variables hanging around that contain the value 0. This isn't
ususally bad in Lingo but as you know, in C it can be a bad thing. It's the
whole nil pointer thing. I don't want to carry over bad habbits into lower
level languages.
-Ron-
- The continuing saga of nulling out an object reference... dp 16:15:41 28.1.97
(0)
D. Plänitz