 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / December 2006[Variable]Stupid question on Type declaration
I have a stupid question ; does it matter to use in a method : this : (a) .......... Indi indis[] /* process ...... */ for (int i=0;i<n;i++) { ....... indis=......; } .......... rather than this : (b) .......... /* process ...... */ for (int i=0;i<n;i++) { ....... Indi indis[]=.....; } .......... more "compact". It makes no difference for the javac compiler as both are accepted ; maybe after compilation it is exactlty the same byte code produced ; in such case (b) could be preferred. Thanks. And thus spoke Daniel Moyne... > I have a stupid question ; does it matter to use in a method : > this : [quoted text clipped - 21 lines] > after compilation it is exactlty the same byte code produced ; in such case > (b) could be preferred. Nope, it isn't the same code. In case b), your indis will be vanished after the for loop is completed, in case a) it's still available, because you defined them outside the for loop. So the big question is: Do you need it outside this loop or not? Flo > And thus spoke Daniel Moyne... > [quoted text clipped - 28 lines] > because you defined them outside the for loop. So the big question is: > Do you need it outside this loop or not? Flo, thanks for the answer ; of course in (b) this is just a for {...} loop variable ; so if this variable has to exist just in for {...} (b) case is the answer but my question was more on the type definition which apparently does not matter when inside a loop as for the compiler the declaration is done just once ! Regards. > Flo, > thanks for the answer ; of course in (b) this is just a for {...} loop [quoted text clipped - 3 lines] > done just once ! > Regards. Im not sure if you realize this but in (b) you will be redefining your "indis" for every iteration of that loop. ie at i=1 you will be losing what was in there at i=0 and so forth. And thus spoke dalouis... > Im not sure if you realize this but in (b) you will be redefining your > "indis" for every iteration of that loop. ie at i=1 you will be losing > what was in there at i=0 and so forth. I think he knows, because that's also the case in (a) :-) Flo > And thus spoke dalouis... > [quoted text clipped - 5 lines] > > Flo Yes looking at it again this might be somewhat obvious but what might not be obvious is that in (b) there is likely to be a re-allocation of memory on every iteration of that loop. The memory space for that array will be marked as unused at the end of each iteration and then at the beginning of the iteration it will be reassigned a new memory location. in (a) while the data is overwritten it will be written to the same memory location each time. Java may be smart enough to fix this in (b) but more likely it will garbage collect the old memory and then reassign a new memory spot. And thus spoke dalouis... > in (a) while the data is overwritten it will be written to the same > memory location each time. Are you sure? Is this somewhere in the language spec? Otherwise I wouldn't know why ... Indi[] i; i = new Indi[x]; i = new Indi[x]; ... should use the exact same memory location for the array both times? If the garbage collector didn't start, the first array will still "exist" somewhere (afaik, of course). And why if somewhere in the loop is an... (static) Indi xyz = i[12]; ...? Perhaps I'm wrong, but I think it would be pure luck if the array goes to the same memory location in every loop cycle in a). Flo > And thus spoke dalouis... > [quoted text clipped - 9 lines] > > ... should use the exact same memory location for the array both times? Maybe the first instance of Indi might still be usable/reachable/whatever when the constructor is invoked the second time. I'm not sure how "magical" arrays are treated in Java, but if their behaviour is specified in some class file, perhaps the JVM cannot assume that the array constructor might not save a reference to itself in some sort of static cache, for example. - Oliver > in (b) there is likely to be a re-allocation of memory on > every iteration of that loop. No, that cannot happen. The Java bytecode has no instructions for doing that. Allocation of stack memory, including local variables, occurs only during the method call operation. An interesting side effect: the variables are also not DE-allocated until the return from the method. As a result, memory referenced by variables which were declared in nested blocks but have gone out of scope will not be garbage collected until the method returns. Theoretically, the compiler COULD automatically stick in code to set the variable to null when the block is exited, but there are many practical reasons not to. Not the least of which is that you could (and should) do it yourself if you really care. Sun's term for local variables that have gone out of scope but have not yet been deallocated is "invisible". See section A.3.3 of http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.