If I understand well, an EdgeIterator can be used only one time. If this is correct, why can't we simply reset it to avoid creating a new instance of EdgeIterator each time we need to loop over the same node edges ?
Thanks !
The EdgeIterator is reused if you use the EdgeExplorer:
// store somewhere
explorer = graph.createEdgeExplorer();
// use somewhere
EdgeIterator iter = explorer.setBaseNode(x);
while(iter) {..}
Still be very careful with this as you need one edgeExplorer for every thread and every loop e.g. having a double for-loop with one explorer will fail :)
Related
I'm looking for some code where 'How to create & code a function which is used ONLY once - EVER! .... at first Start Up of AIR App.??? this I need to download the first set v1.0 of Xml base data files in an AIR Application and after that this particular function should never EVER be addressed again!
Any help would be appreciated regards aktell
a) write a function on init or CreationComplete event.
b) write an object extending objectproxy, introduce a flag, and allow it to use only if the flag is default, and then set the flag to other value.
c) write a static function with a static counter, and when you call it, check if counter != 0, to return, and counter++;
I think you have to use "SharedObject" in this case, so you can set a flag.
On each run the flag will be checked, if true or false you can trigger a function to execute.
Flex Mobile Development: storing data locally
you also can encrypt the stored data
Flex Mobile Development – Encrypting Data
Hope this will workout for you...
Sure you can, use the PersistenceManager to store a flag after first time run ,
for more info about PersistenceManager http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/managers/PersistenceManager.html
Riddle me this: I have my MouseEvent.MOUSE_DOWN which calls mouseHandler. The latter looks something like this:
public function mouseHandler(evt:MouseEvent):void
{
var p:Point = new Point(mouseX, mouseY);
var objs:Array = new Array(getObjectsUnderPoint(p));
}
Now what I want to know is thusly: will the objs array and p point be overwritten every time, simply causing the previous objs array and p point to be wiped and a new one generated, or...does it just create a new array and point over and over and over? Of course if I trace(objs) it gives me the expected results, but am I chocking up the system in the background without realising? Your expertise would be appreciated.
EDIT: well after learning a fair bit from the answerers -thanks btw- that made me think of something else and, a quick search later, found a way to theoretically reliably remove the references:
var a = null;
Now I appreciate that this is probably not needed as they'll be GCed at the end of the function, but considering it takes two ticks to write, better safe than sorry, no?
It works like this from what I understand - references for these variables will be lost after function will end. The values will be GC'ed then eventually.
If you will call the function second time, the new references will be created, and filled with new data, the values of previous references hovewer, may still exist in memory, and wait for Garbage Collector, but that may not necessarily happen! If they have attached listeners, the Flash Player will think that they are still useful, so they will exist in the memory to the end of the application run and listen, and even react to events - even if you theoretically cannot access them anymore.
Edit:
In your case whats happening is that you are creating two references that will disappear at the end of the function. They are not related to event listener, the listener creates them, but is not attached to them so it won't stop GC from collecting them after function will end. You creates an array of references, but that are just references to other objects that values are referred in other places (like the display list), if the array alone is not referred anywhere outside of this function, it should be GCted.
Since p is an object, not a primitive, the memory allocation for it will come from the Heap (and therefore need to be garbage collected) instead of the stack like local primitives (and are wiped once the function ends.
So new memory will be allocated every time this function is called, which will temporarily increase memory usage until they get GC'd, but the amount is probably insignificant (assuming that array isn't massive!).
I have a routine that repeatedly builds and rebuilds a big dynamic movieclip full of buttons called "bigList". When it rebuilds, it first attempts to trash bigList so that it doesn't repeatedly add instances of it to the stage (which it was doing for a while).
I have come up with this code which seems to do the trick:
if (bigList.stage)
{
trace("...bigList exists, better trash it");
bigList.parent.removeChild(bigList);
bigList = null;
bigList = new MovieClip();
trace("...done trashing.");
}
It appears to work... what I am concerned about is garbage collection and memory leaks and such. By doing the above, am I PROPERLY getting rid of the old bigList and replacing it anew, or is there going to be data sitting around in memory that I have to deal with?
To add to that, every time it builds bigList, it adds dozens of dynamically generated mc's, each with an event listener to check for clicks. When I trash bigList each time, are all of those instances and listeners sticking around as well?
Do I need to traverse all of the children of bigList and trash them as well, and their listeners? Is there an efficient way to do that, trash a top-level object and all of its sub-objects and listeners, or am I already getting that with the code I have?
Thanks so much!
The great thing about the garbage collection is that it does most of the work for you. All you have to do is guarantee that there's no references to an object, if that is true then the GC will delete the object from memory at it's own pace (you can't force it to empty at your own chosen time).
From your code sample above, you're doing it great, only one small change I would suggest:
if (bigList.stage)
{
trace("...bigList exists, better trash it");
this.removeChild(bigList); // "bgList.parent" is the same as using "this"
bigList = new MovieClip();
trace("...done trashing.");
}
You don't need to set the variable to null as putting a new MovieClip object into the variable will mean the old object has no reference.
Also, there's no need for the bgList.parent usage as you're already in the parent class. You can even remove the this. to ease readability and reduce clutter but it's good practice to leave it in.
So besides those small recommendations, you're doing a fine job and, based on your sample, you shouldn't have any memory leaks caused by that segment of code.
Adding onto xLite's answer, you can use System.gc() while debugging to force the garbage collection process and check if you've been removing references properly - generally by checking the total RAM usage immediately afterward via System.totalMemoryNumber.
I would like to know what's the difference when I write a temporary variable like this (these are just examples):
version1
for each tempEnemy in enemyManager.enemies {
var tempX:int = tempEnemy.x;
}
or this:
version2
for each tempEnemy in enemyManager.enemies {
tempEnemy.oldX = tempEnemy.x;
}
What's wrong and right? Currently I write it like version 2 and I'm not sure if I should change it to version 1. Can someone help me out with this please? I know most developers write like version 1 but I'm a little bit confused because I am totally unaware about version 1. If I use version 1 does that mean that my value is stored explicitly in a temporary variable that is cleared in every cycle?
Also...
Adding the :variableType (int, String, Number etc) aids in code hinting and debugging.
In version 1 the declaration:
var tempX:int
defines a variable that lasts only as long as that iteration of the for (or for-each) loop it's in. Each iteration tempX is defined, given a value from an Enemy object, and at the end it is left for garbage collection.
In version 2, you reference two variables attached to an Enemy object referenced by the temporary variable named tempEnemy.
In both versions the reference to the Enemy object, tempEnemy, is reassigned the next iteration's Enemy object.
Each method has its advantages. From a memory standpoint, version 2 is probably better, since it changes an existing variable over and over rather than creating a new variable that's discarded at the end of each iteration. On the other hand, version 1 doesn't require you to have oldX defined in its class variables, which can often get mucky enough without these sorts of variables.
Best practices with code are based off of (a) working with other programmers, who need to be able to read and understand the code, and (b) leaving a project and coming back to it later, where you'll need to be able to read and understand your own code. For short projects you don't plan on sharing, version 2 is okay (and probably more memory-efficient), but any large project should use something more like version 1.
Another consideration is, are you going to use that variable anywhere other than the function where it is defined(set)? If not, you don't need to store it in the object, which points again to version 1.
What if you call a (non-void) function, but don't assign its return value to a variable?
e.g., getchar();
I've always wondered what happens to such a value. I've heard humorous explanations like "its gone to the ether" and so forth, but I'd really like to know really. Would there be any way to recover such a value?
Thanks
This is really compiler / CPU specific, but in most cases the return value will be in a CPU register (if it will fit), and if that register is not touched by the subsequent code, you could retrieve it using e.g. "inline assembler".
To answer your question better, nothing "happens" to the value. It sits in a stack-location or inside a register. If you use it, fine... if not, nothing happens really. Eventually the stack or register is overwritten by new values...
No, you won't.
The value gets popped off the stack and is gone.
If you need the return value, you should assign it to a variable.
Simply 'returning' (either by implicitly calling return by itself or not returning at all) and not assigning a value does just that, doesn't assign a value and thus is null.
If you want to learn more about how it all works, you can look at this: http://en.wikipedia.org/wiki/Call_stack