tags:

views:

181

answers:

3
+2  Q: 

java for each loop

How is Java's for loop code generated by compiler?

For example , if I have:

for(String s : getStringArray() )
{
   //do something with s
}

where getStringArray() is a function that returns the Array I want to loop on, would function be called always or only once ? How optimal is code for looping using this construct is , in general ?

+1  A: 

Compiler might call it just once, but you can depend on it. It may not be a good coding practice. If getStringArray() returns same array each time, why not set to a variable first?

EDIT - answer changed with the comments received.

fastcodejava
You *can* in fact depend on it being called once. See http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2
Greg Hewgill
I think it's fine to invoke methods in `Expression`, within reason. `for (char c : str.toCharArray())`, `for (MyEnum e : MyEnum.values())`, etc seems idiomatic.
polygenelubricants
+4  A: 

The Java Language Specification details exactly what the foreach statement does. See 14.14.2 The enhanced for statement for more information.

Greg Hewgill
+11  A: 

On the semantics of enhanced for loop

Here is the relevant excerpts from the Java Language Specification 3rd Edition, slightly edited for clarity:

JLS 14.14.2 The enhanced for statement

The enhanced for statement has the form:

for ( Type Identifier : Expression ) Statement

If the type of Expression is an array type, T[], then the meaning of the enhanced for statement is given by the following basic for statement:

T[] a = Expression;
for (int i = 0; i < a.length; i++) {
    Type Identifier = a[i];
    Statement
}

where a and i are compiler-generated identifiers that are distinct from any other identifiers (compiler-generated or otherwise) that are in scope at the point where the enhanced for statement occurs.

So in fact the language does guarantee that Expression will only be evaluated once.

For completeness, here's the equivalence when the Expression is of type Iterable:

JLS 14.14.2 The enhanced for statement

The enhanced for statement has the form:

for ( Type Identifier : Expression ) Statement

If the type of Expression is a subtype of Iterable, then let I be the type of the expression Expression.iterator(). The enhanced for statement is equivalent to a basic for statement of the form:

for (I iter = Expression.iterator(); iter.hasNext(); ) {
    Type Identifier = iter.next();
    Statement
}

where iter is a compiler-generated identifier that is distinct from any other identifiers (compiler-generated or otherwise) that are in scope at the point where the enhanced for statement occurs.

Note that it is a compile-time error if Expression is neither an Iterable nor an array, so the above two are the only cases where you can use an enhanced for loop. Also, for clarity, the above quotes leave out information regarding any labels attached on the for loop and any modifiers attached on the Identifier, but these are handled as one would expect.


On the performance of enhanced for loop

Here's a quote from Effective Java 2nd Edition, Item 46: Prefer for-each loops to traditional for loops

The for-each loop, introduced in release 1.5, gets rid of the clutter and the opportunity for error by hiding the iterator or index variable completely. The resulting idiom applies equally to collections and arrays. Note that there is no performance penalty for using the for-each loop, even for arrays. In fact, it may offer a slight performance advantage over an ordinary for loop in some circumstances, as it computes the limit of the array index only once. While you can do this by hand, programmers don't always do so.

Thus the book claims that in fact some compilers go beyond the JLS translation and performs additional optimization on the for-each loop (while still maintaining its semantics, of course).

In summary, you should not worry about the performance of for-each loop. The specification by the language is sensible (Expression only evaluated once), and precisely because this is the preferred construct in many scenarios, compilers will make sure to optimize them as best they can.

See also

polygenelubricants