I was going through some exercises but I am confused in this one:
public static int f (int x, int y) {
int b=y--;
while (b>0) {
if (x%2!=0) {
--x;
y=y-2;
}
else {
x=x/2;
b=b-x-1;
}
}
return x+y;
}
What is the purpose of b=y--?
So, for example, x=5 and y=5
when we first go inside of while loop (while (b>0)) will b = 4 or 5? When I am running the code in my computer b is 5. And the return is 3. It is really unclear to me. Sorry if I am unclear in my question.
int b=y--; first assignes b=y and then decrements y (y--).
Also take a look at the prefix/postfix unary increment operator.
This example (taken from the linked page) demonstrates it:
class PrePostDemo {
public static void main(String[] args){
int i = 3;
i++;
// prints 4
System.out.println(i);
++i;
// prints 5
System.out.println(i);
// prints 6
System.out.println(++i);
// prints 6
System.out.println(i++);
// prints 7
System.out.println(i);
}
}
The difference between a post-increment/decrement and a pre-increment/decrement is in the evaluation of the expression.
The pre-increment and pre-decrement operators increment (or decrement) their operand by 1, and the value of the expression is the resulting incremented (or decremented) value. In contrast, the post-increment and post-decrement operators increase (or decrease) the value of their operand by 1, but the value of the expression is the operand's original value prior to the increment (or decrement) operation.
In other words:
int a = 5;
int b;
b = --a; // the value of the expression --a is a-1. b is now 4, as is a.
b = a--; // the value of the expression a-- is a. b is still 4, but a is 3.
Remember that a program must evaluate expressions to do everything. Everything is an expression, even just a casual mention of a variable. All of the following are expressions:
a
a-1
--a && ++a
System.out.println(a)
Of course, in the evaluation of expressions, operator precedence dictates the value of an expression just as the PEMDAS you learned in grade school. Some operators, such as increment/decrement, have side effects, which is of course great fun, and one of the reasons why functional programming was created.
I believe b would equal 5 entering the loop because
b=y--;
When the "--" is behind the variable it decrements it after the action.
It's poor coding, as it can confuse new programmers.
The function, assuming it is passing by value, like in the example above (as opposed to passing by reference) takes a copy of y, decrements it, and assigns it to b. It does not alter the argument passed to the function when it was called.
Post increment
x++;
x += 1;
Post decrement
x--;
x -=1;
Pre increment : ++x;
Pre decrement : --x;
According to the Head First Java:
Difference between x++ and ++x :
int x = 0; int z = ++x;
Produces: x is 1, x is 1
in x = 0; int z = x++;
Produces: x is 1, z is 0
This question already has answers here:
Post-increment and Pre-increment concept?
(14 answers)
Java: Prefix/postfix of increment/decrement operators
(11 answers)
Closed 6 years ago.
I'm trying to learn java oop and i find some problem understanding why the use of post-increment in Recursive Method cause error ? I don't understand .
Main Class :
public class Main {
public static void main(String[] args) {
A a = new A();
a.res(0);
}
}
Code work fine :
public class A {
public void res(int a){
if (a < 5)
res(a+1);
System.out.println(a);
}
}
Output : run:
5
4
3
2
1
0
BUILD SUCCESSFUL (total time: 0 seconds)
But in when i use the ++ operator i got StackOverflowError .
public class A {
public void res(int a){
if (a < 5)
res(a++);
System.out.println(a);
}
}
You are confusing a++ and ++a. As per java documentation - "The only difference is that the prefix version (++result) evaluates to the incremented value, whereas the postfix version (result++) evaluates to the original value".
In your case the recursive method is always called with the argument 0
The post-increment operator increments the variable after you use it, so it will only increment the variable after the recursive function is returned.
Your code is doing this:
res(a++) //a = 0
//now a = 1
The recursion will never reach that next line, so the recursive function will always call res(0)
References: https://stackoverflow.com/a/2371162/7238307
Well... what do you expect, exactly? Let's re-write your program slightly. Your program (the one that crashes) can effectively be re-written like so, achieving the same effect (that is, crashing due to a StackOverflowError):
public class A {
public void res(int a){
if (a < 5) {
res(a);
++a;
}
System.out.println(a);
}
}
Your variable a will only increment after the recursive call to res has completed... which is never, because you're always invoking res with the same value.
This is how the recusrive calls are resolved with a+1.
a=0, res(0)
+ 0 < 5, res(1)
++ 1 < 5, res(2)
+++ 2 < 5, res(3)
++++ 3 < 5, res(4)
+++++ 4 < 5, res(5)
++++++ 5 = 5, print 5
+++++ print 4
++++ print 3
+++ print 2
++ print 1
+ print 0
Regarding the problem of your code with a++ is that the increment is performed after the the recursive call is performed. So you basically get:
a=0, res(0)
+ 0 < 5, res(0)
++ 0 < 5, res(0)
+++ ...
This question already has answers here:
How do the post increment (i++) and pre increment (++i) operators work in Java?
(14 answers)
Closed 5 years ago.
How is this possible as post increment operator should increase x to 66?
When I did the same for y= ++x + ++x + x++; it gave a value 65 for y and 23 for x.
So let me know how is java compilers solving these expression.
Let Java show you. javap -c MyClass shows you bytecode:
public static void main(java.lang.String[]);
Code:
0: bipush 20
2: istore_1
3: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
6: iinc 1, 1
9: iload_1
10: iinc 1, 1
13: iload_1
14: iadd
15: iload_1
16: iinc 1, 1
19: iadd
20: dup
21: istore_1
22: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
25: return
And the result is completely logical if you think about it: you have two preincrements and one postincrement. So, your code is in effect:
y = 0
x++ // 21
y += x
x++ // 22
y += x
y += x // (still 22!)
x++ // 23
x = y // (21 + 22 + 22 at this point)
++x is different from x++
++x increments x before any operations done in that same line.
x++ increments x after any operations done in the same line.
For it to calculate to 65, it must be doing a calculation like the following.
(1+20)+(1+21)+(22)= 65
Afterwards, x would be 23
I think that y= （++20） + (++21) + 22 = 21 + 22 +22 = 65
So let me know how is java compilers solving these expression.
Java compiler are simply implementing the Java Language Specification.
If you really need to understand how compiler evaluates horrible and bizarre statements like that, you need to understand the relevant parts of the spec:
15.7 Evaluation Order
15.14.2 Postfix Increment Operator ++
15.15.1 Prefix Increment Operator ++
and so on.
First, you should understand this:
++i increments i and returns i.
i++ returns i and then increments it.
Now that we have established this, let's break the program down.
At the start of your program, x = 20. So, ++x would return 21. Now when you increment x in this fashion again, you will be incrementing 21 and not 20. So, ++x + ++x will evaluate to 21 + 22 which equals 43. At this point in the program, x equals 22. So if you add x++ to 43, you will add the value of x to 43 and only then increment x. This ultimately results in y having a value of 65, and x having a value of 23.
don't use ++ and = on the same variable in the same expression, the increment will not take into effect. from Java™ Puzzlers: Traps, Pitfalls, and Corner Cases By Joshua Bloch, Neal Gafter
Puzzle #25:
As the puzzle's title suggests, the problem lies in the statement that does the increment:
j = j++;
Presumably, the author of the statement meant for it to add 1 to the
value of j, which is what the expression j++ does. Unfortunately, the
author inadvertently assigned the value of this expression back to j.
When placed after a variable, the ++ operator functions as the postfix
increment operator [JLS 15.14.2]: The value of the expression j++ is
the original value of j before it was incremented. Therefore, the
preceding assignment first saves the value of j, then sets j to its
value plus 1, and, finally, resets j back to its original value. In
other words, the assignment is equivalent to this sequence of
statements:
int tmp = j;
j = j + 1;
j = tmp;
as a result your doe looks like this when it evaluates:
int x=20
int sum;
x=x+1; //x=20=1
sum=x; //sum and x equal 21
x=x+1; //x=22
sum=sum+x; //sum=43
sum= sum+x; //sum=65
x= x+1; //x=23
x=sum; //x=65;
This is why x=65 and not 66
Overall this is bad programming and should never ever be used in actual code because it is easy to get lost in all the pre and post increments.
But here is the basic explanation.
simple enough:
x = 20
Here is where it gets messy:
y = ++(20) + ++(++(20)) + (++(++(20)))++
Pre increment --> ++x
Post increment --> x++
Pre increments happen inside the evaluation and post
increments happen after the evaluation.
So that statement can be reduced in the following steps.
y = 21 + ++(21) + (++(21))++
y = 21 + 22 + (22)++
y = 21 + 22 + 22
y = 65
After all these increments x = 23. In the statement above though, x equals multiple
numbers because of all the pre and post increments.
Moral of the story, don't ever do this and pre increments take place before the expression is evaluated and post increments take place after the expression is evaluated.
You should remember this C Operator Precedence
so post increment goes first ++X = 20
then x++=22 then
x++ = 23 so total 65.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
post increment operator java
What is x after “x = x++”?
Can somebody explain me the result of each one of the following small programs? :
public static void main(String[] args) {
int a = 10;
a = a++;
System.out.println(a);
}
The result is: 10
Why not 11 since a should have been increased after the assignment? Is that the fact that it comes to different variables left and right of the opeartor = ?
The next one:
public static void main(String[] args) {
int a = 10;
a = ++a;
System.out.println(a);
}
The result is: 11
Comprehensible, but the compiler presents the warning: "The assignment to variable a has no effect". The result dissents though.
Update:
I do not modify my original question but I add this comment to clarify that now I catch the meaning of the warning. That is, even without the assignment (by a plain statement ++a) the result would be the same (11).
The value of a++ is a. ++ has higher precedence than =. So:
The value of a is taken.
a is incremented.
The value as at (1) is stored into a.
So the value of a doesn't change.
You can figure out yourself what happens in the second case.
In first case assignment happens first and then increment. So you get value which was before increment. But in second case it gets incremented first and then gets assigned.
Lets analyze the Byte code produced in each way -
int a = 10;
a = a++;
System.out.println(a); //Output - 10
produced ByteCode -
0 bipush
2 istore_1
3 iload_1
4 iinc
7 istore_1
8 getstatic
11 iload_1
12 invokevirtual
15 return
and
int a = 10;
a = ++a;
System.out.println(a); //Output -11
Here compiler give warning - The assignment to variable a has no effect
Produced ByteCode -
0 bipush
2 istore_1
3 iinc
6 iload_1
7 istore_1
8 getstatic
11 iload_1
12 invokevirtual
15 return
Here we can see in 1st case variable load first then increment so it does not effect anything to variable a.
Where as 2nd case it first increment then load the variable so it got effect of increment.
This happens because a++ is more like a Method then a realistic Number.
you can splitt them into two seperat lines.
the first one would be
a = a;
return a + 1;
the seconde one would be
a = a+1;
a++ means increase the value of variable a, however a++ has the original value of a!
a = ?? means set the value of a to ??
So what you are doing is incrementing the value of a by one, and then setting it to the old value.
++a means increase the value of variable a, however ++a has the new value of a!
So in the second example you are incrementing the value of a, and then setting the value of a to that value (it has just gotten), so you are doing the same twice.
a++ is equivalent to a = a + 1 but increments after the value is used in expression (assignment here) ++a is same but increments before its used in expression. a = ++a; has no explicit assignment affect as it is equal to a = a = a + 1
When you write a++ it means a will increment AFTER the '=' operator has been processed. So
b = a++;
System.out.println(a);
System.out.println(b);
Should produce on your screen: 11, 10. Because a becomes 11 after b takes the value of 'a'. If you change the a++ to ++a you force the increment to happen before the '=' is processed so you will be giving b = a + 1 and on your screen you should be having 11,11.
I have always wondered if, in general, declaring a throw-away variable before a loop, as opposed to repeatedly inside the loop, makes any (performance) difference?
A (quite pointless) example in Java:
a) declaration before loop:
double intermediateResult;
for(int i=0; i < 1000; i++){
intermediateResult = i;
System.out.println(intermediateResult);
}
b) declaration (repeatedly) inside loop:
for(int i=0; i < 1000; i++){
double intermediateResult = i;
System.out.println(intermediateResult);
}
Which one is better, a or b?
I suspect that repeated variable declaration (example b) creates more overhead in theory, but that compilers are smart enough so that it doesn't matter. Example b has the advantage of being more compact and limiting the scope of the variable to where it is used. Still, I tend to code according example a.
Edit: I am especially interested in the Java case.
Which is better, a or b?
From a performance perspective, you'd have to measure it. (And in my opinion, if you can measure a difference, the compiler isn't very good).
From a maintenance perspective, b is better. Declare and initialize variables in the same place, in the narrowest scope possible. Don't leave a gaping hole between the declaration and the initialization, and don't pollute namespaces you don't need to.
Well I ran your A and B examples 20 times each, looping 100 million times.(JVM - 1.5.0)
A: average execution time: .074 sec
B: average execution time : .067 sec
To my surprise B was slightly faster.
As fast as computers are now its hard to say if you could accurately measure this.
I would code it the A way as well but I would say it doesn't really matter.
It depends on the language and the exact use. For instance, in C# 1 it made no difference. In C# 2, if the local variable is captured by an anonymous method (or lambda expression in C# 3) it can make a very signficant difference.
Example:
using System;
using System.Collections.Generic;
class Test
{
static void Main()
{
List<Action> actions = new List<Action>();
int outer;
for (int i=0; i < 10; i++)
{
outer = i;
int inner = i;
actions.Add(() => Console.WriteLine("Inner={0}, Outer={1}", inner, outer));
}
foreach (Action action in actions)
{
action();
}
}
}
Output:
Inner=0, Outer=9
Inner=1, Outer=9
Inner=2, Outer=9
Inner=3, Outer=9
Inner=4, Outer=9
Inner=5, Outer=9
Inner=6, Outer=9
Inner=7, Outer=9
Inner=8, Outer=9
Inner=9, Outer=9
The difference is that all of the actions capture the same outer variable, but each has its own separate inner variable.
The following is what I wrote and compiled in .NET.
double r0;
for (int i = 0; i < 1000; i++) {
r0 = i*i;
Console.WriteLine(r0);
}
for (int j = 0; j < 1000; j++) {
double r1 = j*j;
Console.WriteLine(r1);
}
This is what I get from .NET Reflector when CIL is rendered back into code.
for (int i = 0; i < 0x3e8; i++)
{
double r0 = i * i;
Console.WriteLine(r0);
}
for (int j = 0; j < 0x3e8; j++)
{
double r1 = j * j;
Console.WriteLine(r1);
}
So both look exactly same after compilation. In managed languages code is converted into CL/byte code and at time of execution it's converted into machine language. So in machine language a double may not even be created on the stack. It may just be a register as code reflect that it is a temporary variable for WriteLine function. There are a whole set optimization rules just for loops. So the average guy shouldn't be worried about it, especially in managed languages. There are cases when you can optimize manage code, for example, if you have to concatenate a large number of strings using just string a; a+=anotherstring[i] vs using StringBuilder. There is very big difference in performance between both. There are a lot of such cases where the compiler cannot optimize your code, because it cannot figure out what is intended in a bigger scope. But it can pretty much optimize basic things for you.
This is a gotcha in VB.NET. The Visual Basic result won't reinitialize the variable in this example:
For i as Integer = 1 to 100
Dim j as Integer
Console.WriteLine(j)
j = i
Next
' Output: 0 1 2 3 4...
This will print 0 the first time (Visual Basic variables have default values when declared!) but i each time after that.
If you add a = 0, though, you get what you might expect:
For i as Integer = 1 to 100
Dim j as Integer = 0
Console.WriteLine(j)
j = i
Next
'Output: 0 0 0 0 0...
I made a simple test:
int b;
for (int i = 0; i < 10; i++) {
b = i;
}
vs
for (int i = 0; i < 10; i++) {
int b = i;
}
I compiled these codes with gcc - 5.2.0. And then I disassembled the main ()
of these two codes and that's the result:
1º:
0x00000000004004b6 <+0>: push rbp
0x00000000004004b7 <+1>: mov rbp,rsp
0x00000000004004ba <+4>: mov DWORD PTR [rbp-0x4],0x0
0x00000000004004c1 <+11>: jmp 0x4004cd <main+23>
0x00000000004004c3 <+13>: mov eax,DWORD PTR [rbp-0x4]
0x00000000004004c6 <+16>: mov DWORD PTR [rbp-0x8],eax
0x00000000004004c9 <+19>: add DWORD PTR [rbp-0x4],0x1
0x00000000004004cd <+23>: cmp DWORD PTR [rbp-0x4],0x9
0x00000000004004d1 <+27>: jle 0x4004c3 <main+13>
0x00000000004004d3 <+29>: mov eax,0x0
0x00000000004004d8 <+34>: pop rbp
0x00000000004004d9 <+35>: ret
vs
2º
0x00000000004004b6 <+0>: push rbp
0x00000000004004b7 <+1>: mov rbp,rsp
0x00000000004004ba <+4>: mov DWORD PTR [rbp-0x4],0x0
0x00000000004004c1 <+11>: jmp 0x4004cd <main+23>
0x00000000004004c3 <+13>: mov eax,DWORD PTR [rbp-0x4]
0x00000000004004c6 <+16>: mov DWORD PTR [rbp-0x8],eax
0x00000000004004c9 <+19>: add DWORD PTR [rbp-0x4],0x1
0x00000000004004cd <+23>: cmp DWORD PTR [rbp-0x4],0x9
0x00000000004004d1 <+27>: jle 0x4004c3 <main+13>
0x00000000004004d3 <+29>: mov eax,0x0
0x00000000004004d8 <+34>: pop rbp
0x00000000004004d9 <+35>: ret
Which are exaclty the same asm result. isn't a proof that the two codes produce the same thing?
It is language dependent - IIRC C# optimises this, so there isn't any difference, but JavaScript (for example) will do the whole memory allocation shebang each time.
I would always use A (rather than relying on the compiler) and might also rewrite to:
for(int i=0, double intermediateResult=0; i<1000; i++){
intermediateResult = i;
System.out.println(intermediateResult);
}
This still restricts intermediateResult to the loop's scope, but doesn't redeclare during each iteration.
In my opinion, b is the better structure. In a, the last value of intermediateResult sticks around after your loop is finished.
Edit:
This doesn't make a lot of difference with value types, but reference types can be somewhat weighty. Personally, I like variables to be dereferenced as soon as possible for cleanup, and b does that for you,
I suspect a few compilers could optimize both to be the same code, but certainly not all. So I'd say you're better off with the former. The only reason for the latter is if you want to ensure that the declared variable is used only within your loop.
As a general rule, I declare my variables in the inner-most possible scope. So, if you're not using intermediateResult outside of the loop, then I'd go with B.
A co-worker prefers the first form, telling it is an optimization, preferring to re-use a declaration.
I prefer the second one (and try to persuade my co-worker! ;-)), having read that:
It reduces scope of variables to where they are needed, which is a good thing.
Java optimizes enough to make no significant difference in performance. IIRC, perhaps the second form is even faster.
Anyway, it falls in the category of premature optimization that rely in quality of compiler and/or JVM.
There is a difference in C# if you are using the variable in a lambda, etc. But in general the compiler will basically do the same thing, assuming the variable is only used within the loop.
Given that they are basically the same: Note that version b makes it much more obvious to readers that the variable isn't, and can't, be used after the loop. Additionally, version b is much more easily refactored. It is more difficult to extract the loop body into its own method in version a. Moreover, version b assures you that there is no side effect to such a refactoring.
Hence, version a annoys me to no end, because there's no benefit to it and it makes it much more difficult to reason about the code...
Well, you could always make a scope for that:
{ //Or if(true) if the language doesn't support making scopes like this
double intermediateResult;
for (int i=0; i<1000; i++) {
intermediateResult = i;
System.out.println(intermediateResult);
}
}
This way you only declare the variable once, and it'll die when you leave the loop.
I think it depends on the compiler and is hard to give a general answer.
I've always thought that if you declare your variables inside of your loop then you're wasting memory. If you have something like this:
for(;;) {
Object o = new Object();
}
Then not only does the object need to be created for each iteration, but there needs to be a new reference allocated for each object. It seems that if the garbage collector is slow then you'll have a bunch of dangling references that need to be cleaned up.
However, if you have this:
Object o;
for(;;) {
o = new Object();
}
Then you're only creating a single reference and assigning a new object to it each time. Sure, it might take a bit longer for it to go out of scope, but then there's only one dangling reference to deal with.
My practice is following:
if type of variable is simple (int, double, ...) I prefer variant b (inside).
Reason: reducing scope of variable.
if type of variable is not simple (some kind of class or struct) I prefer variant a (outside).
Reason: reducing number of ctor-dtor calls.
I had this very same question for a long time. So I tested an even simpler piece of code.
Conclusion: For such cases there is NO performance difference.
Outside loop case
int intermediateResult;
for(int i=0; i < 1000; i++){
intermediateResult = i+2;
System.out.println(intermediateResult);
}
Inside loop case
for(int i=0; i < 1000; i++){
int intermediateResult = i+2;
System.out.println(intermediateResult);
}
I checked the compiled file on IntelliJ's decompiler and for both cases, I got the same Test.class
for(int i = 0; i < 1000; ++i) {
int intermediateResult = i + 2;
System.out.println(intermediateResult);
}
I also disassembled code for both the case using the method given in this answer. I'll show only the parts relevant to the answer
Outside loop case
Code:
stack=2, locals=3, args_size=1
0: iconst_0
1: istore_2
2: iload_2
3: sipush 1000
6: if_icmpge 26
9: iload_2
10: iconst_2
11: iadd
12: istore_1
13: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
16: iload_1
17: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
20: iinc 2, 1
23: goto 2
26: return
LocalVariableTable:
Start Length Slot Name Signature
13 13 1 intermediateResult I
2 24 2 i I
0 27 0 args [Ljava/lang/String;
Inside loop case
Code:
stack=2, locals=3, args_size=1
0: iconst_0
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 26
9: iload_1
10: iconst_2
11: iadd
12: istore_2
13: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
16: iload_2
17: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
20: iinc 1, 1
23: goto 2
26: return
LocalVariableTable:
Start Length Slot Name Signature
13 7 2 intermediateResult I
2 24 1 i I
0 27 0 args [Ljava/lang/String;
If you pay close attention, only the Slot assigned to i and intermediateResult in LocalVariableTable is swapped as a product of their order of appearance. The same difference in slot is reflected in other lines of code.
No extra operation is being performed
intermediateResult is still a local variable in both cases, so there is no difference access time.
BONUS
Compilers do a ton of optimization, take a look at what happens in this case.
Zero work case
for(int i=0; i < 1000; i++){
int intermediateResult = i;
System.out.println(intermediateResult);
}
Zero work decompiled
for(int i = 0; i < 1000; ++i) {
System.out.println(i);
}
From a performance perspective, outside is (much) better.
public static void outside() {
double intermediateResult;
for(int i=0; i < Integer.MAX_VALUE; i++){
intermediateResult = i;
}
}
public static void inside() {
for(int i=0; i < Integer.MAX_VALUE; i++){
double intermediateResult = i;
}
}
I executed both functions 1 billion times each.
outside() took 65 milliseconds. inside() took 1.5 seconds.
I tested for JS with Node 4.0.0 if anyone is interested. Declaring outside the loop resulted in a ~.5 ms performance improvement on average over 1000 trials with 100 million loop iterations per trial. So I'm gonna say go ahead and write it in the most readable / maintainable way which is B, imo. I would put my code in a fiddle, but I used the performance-now Node module. Here's the code:
var now = require("../node_modules/performance-now")
// declare vars inside loop
function varInside(){
for(var i = 0; i < 100000000; i++){
var temp = i;
var temp2 = i + 1;
var temp3 = i + 2;
}
}
// declare vars outside loop
function varOutside(){
var temp;
var temp2;
var temp3;
for(var i = 0; i < 100000000; i++){
temp = i
temp2 = i + 1
temp3 = i + 2
}
}
// for computing average execution times
var insideAvg = 0;
var outsideAvg = 0;
// run varInside a million times and average execution times
for(var i = 0; i < 1000; i++){
var start = now()
varInside()
var end = now()
insideAvg = (insideAvg + (end-start)) / 2
}
// run varOutside a million times and average execution times
for(var i = 0; i < 1000; i++){
var start = now()
varOutside()
var end = now()
outsideAvg = (outsideAvg + (end-start)) / 2
}
console.log('declared inside loop', insideAvg)
console.log('declared outside loop', outsideAvg)
A) is a safe bet than B).........Imagine if you are initializing structure in loop rather than 'int' or 'float' then what?
like
typedef struct loop_example{
JXTZ hi; // where JXTZ could be another type...say closed source lib
// you include in Makefile
}loop_example_struct;
//then....
int j = 0; // declare here or face c99 error if in loop - depends on compiler setting
for ( ;j++; )
{
loop_example loop_object; // guess the result in memory heap?
}
You are certainly bound to face problems with memory leaks!. Hence I believe 'A' is safer bet while 'B' is vulnerable to memory accumulation esp working close source libraries.You can check usinng 'Valgrind' Tool on Linux specifically sub tool 'Helgrind'.
It's an interesting question. From my experience there is an ultimate question to consider when you debate this matter for a code:
Is there any reason why the variable would need to be global?
It makes sense to only declare the variable once, globally, as opposed to many times locally, because it is better for organizing the code and requires less lines of code. However, if it only needs to be declared locally within one method, I would initialize it in that method so it is clear that the variable is exclusively relevant to that method. Be careful not to call this variable outside the method in which it is initialized if you choose the latter option--your code won't know what you're talking about and will report an error.
Also, as a side note, don't duplicate local variable names between different methods even if their purposes are near-identical; it just gets confusing.
this is the better form
double intermediateResult;
int i = byte.MinValue;
for(; i < 1000; i++)
{
intermediateResult = i;
System.out.println(intermediateResult);
}
1) in this way declared once time both variable, and not each for cycle.
2) the assignment it's fatser thean all other option.
3) So the bestpractice rule is any declaration outside the iteration for.
Tried the same thing in Go, and compared the compiler output using go tool compile -S with go 1.9.4
Zero difference, as per the assembler output.
I use (A) when I want to see the contents of the variable after exiting the loop. It only matters for debugging. I use (B) when I want the code more compact, since it saves one line of code.
Even if I know my compiler is smart enough, I won't like to rely on it, and will use the a) variant.
The b) variant makes sense to me only if you desperately need to make the intermediateResult unavailable after the loop body. But I can't imagine such desperate situation, anyway....
EDIT: Jon Skeet made a very good point, showing that variable declaration inside a loop can make an actual semantic difference.