I am working through some exercises and was wondering if someone could explain how int a and a = 15 are referenced separately?
public class SwapVariables {
public static void main(String[] args) {
int a, b;
a = 15;
b = 27;
System.out.println("Before swap: a = "+a+" b = "+b);
a = a + b;
b = a - b;
a = a - b;
System.out.println("After swap: a = "+a+" b = "+b);
}
}
Good answer by Elliot, but to get a better understanding how it works. At the beginning you are declaring two variables a and b. Those are just references in memory in a zone that is 4 bytes each in size (int in java is 32 bits). In the second line you are saying go to those 4 bytes which i "called" them a and give them the name "a" and make their value 15. So in memory you are performing a write process. Same thing for b. Next you are performing a read at the beginning and after that a write. You are saying go to the "a" point in memory and get the value, go to the "b" point in memory and get the value and perform addition which is 42. Take the result and go write it in the "a" point in memory. Now "a" has a new value and the old value is changed. Unless a change in that memory zone happens the value of a will be 42. The same logic is applied in the all the subsequent rows. Hope it helps for a better understanding!
They are not "referenced", because they are primitive value types.
a = 15 + 27 = 42
b = 42 - 27 = 15
a = 42 - 15 = 27
tl;dr Math.
Related
What happens if you change the variable b, or what if you change a. What does the order have to do with anything.
I know count = count + 1 but the two variables is messing up my brain.
b = 7;
a = 7;
a = b;
a += 1;
What happens to b?
What happens to b?
Nothing happens to b.
When you do
a = b;
you're copying the value stored in b and putting it in a. (You're not making a an alias of b.)
When you then do a += 1; you're changing the value stored in a (and the value stored in b remains unchanged).
You can verify this by printing the final values after your code snippet:
System.out.println(a); // prints 8
System.out.println(b); // prints 7
What happens if you change the variable b, or what if you change a. What does the order have to do with anything.
a and b are two independent variables and changing one will never affect the other.
The order matters since when you do a = b the value of b is copied into a and whatever a stored before is discarded. If you had done a += 1 prior to a = b, then a would have been restored to 7 again.
int is raw type you don't copy reference but the value itself. This will work same way for Integer because it is immutable class.
int b = 7;
int a = 7;
a = b;
a+=1;
System.out.println(a);// ->8
System.out.println(b);// ->7
Still 7.
integer is raw type and if you assign a int variable to another int, just its value is received by the new one. Not the object itself.
b stays 7.
a becomes 8.
You could use System.out.println(); to print values of variables and find out yourself if you ever doubt.
That or use the debugger.
public static void main(String[] args) {
int b = 7; // b points to 7
int a = 7; // a points to 7
a = b; // b and a points to 7
a += 1; // a points to 8 now, b is still pointing to 7
System.out.println(a);
System.out.println(b);
}
output
8
7
When we do a += 1; we change the value stored in a (value stored in b is still same).
I'm working on Project Euler Problem 9, which states:
A Pythagorean triplet is a set of three natural numbers, a < b < c, for which,
a^2 + b^2 = c^2
For example, 3^2 + 4^2 = 9 + 16 = 25 = 52.
There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.
Here's what I've done so far:
class Project_euler9 {
public static boolean determineIfPythagoreanTriple(int a, int b, int c) {
return (a * a + b * b == c * c);
}
public static void main(String[] args) {
boolean answerFound = false;
int a, b, c;
while (!answerFound) {
for (a = 1; a <= 1000; a++) {
for (b = a + 1; b <= 1000; b++) {
c = 1000 - a - b;
answerFound = determineIfPythagoreanTriple(a, b, c);
}
}
}
System.out.println("(" + a + ", " + b + ", " + c + ")");
}
}
When I run my code, I get this error:
Project_euler9.java:32: error: variable a might not have been initialized
System.out.println("The Pythagorean triplet we're looking for is (" + a + ", " + b + ", " + c + ")");
Note: I get this for each of my variables (a, b, and c) just with different line numbers.
I thought that when I declared a, b, and c as integers, the default value was 0 if left unassigned.
Even if this weren't the case, it looks to me like they all do get assigned, so I'm a bit confused about the error.
Why is this happening?
Instance variables (in your case, they would be integers) are assigned to 0 be default. Local variables not. (From Java Docs)
If the loop is not entered, then your variables won't be initialized, that's the reason of the error.
What you can do is initialize them when declaring:
int a=0, b=0, c=0;
Your problem is this line:
System.out.println("(" + a + ", " + b + ", " + c + ")");
which is after the while (!answerFound) {...} loop. The compiler thinks that there may be a case where one or more of the variables a, b or c isn't initialised.
Use this line:
int a=0, b=0, c=0;
when declaring the variables, so that they are initialised when declared, and the error should go away.
Do this, at the beginning of the method after the local variables are declared:
a = b = c = 0;
The error is basically stating that Java can't be sure that the variables have a value assigned when they reach the System.out.println(). Remember: in Java only attributes have default values, all local variables must be explicitly initialized at some point.
You're right and wrong in your thinking:
Where you're right:
Yes, uninitialized variables may be assigned a value by the compiler, but a) it is considered bad style, b) You shouldn't depend on it, c) That does not apply to local variables (as declared in a method)
Where you are wrong:
Local variables are not assigned a default value, only instance variables.
For reference, take a look at The docs:
Default Values
It's not always necessary to assign a value when a field is declared.
Fields that are declared but not initialized will be set to a
reasonable default by the compiler. Generally speaking, this default
will be zero or null, depending on the data type. Relying on such
default values, however, is generally considered bad programming
style.
The following chart summarizes the default values for the above data
types.
Data Type Default Value (for fields)
byte 0
short 0
int 0
long 0L
float 0.0f
double 0.0d char '\u0000' String (or any object) null
boolean false
Local variables are slightly different; the compiler never assigns a
default value to an uninitialized local variable. If you cannot
initialize your local variable where it is declared, make sure to
assign it a value before you attempt to use it. Accessing an
uninitialized local variable will result in a compile-time error.
When you declare local variables in a method, you have to assign them values before use them.
The Java compiler has to be convinced that when we get to the line HERE, it can prove that a, b, and c have been set to something:
boolean answerFound = false;
int a, b, c;
while (!answerFound) {
for (a = 1; a <= 1000; a++) {
for (b = a + 1; b <= 1000; b++) {
c = 1000 - a - b;
answerFound = determineIfPythagoreanTriple(a, b, c);
}
}
}
// HERE
From the compiler's point of view, if the loop is executed zero times, then it will get to HERE without the variables being initialized; therefore, you can't use them. We know that this is impossible, because we know that answerFound is initialized to false and therefore the loop will be executed at least once, and also that each for loop will be executed at least once. But the language has to have consistent rules to determine which programs are legal and which ones aren't; in order to keep things from being overly complex, the compiler isn't required to make the kinds of deductions that would be necessary to prove that a, b, and c are always initialized. I haven't looked at the actual "definite assignment" rules in detail, but I think they're already fairly complex.
So even though you know that the variables will be initialized, you can't convince the compiler of that. So just initialize them when they're declared.
int a = 0, b = 0, c = 0;
By the way, since the while is outside the for loops, this code will not exit right away when answerFound becomes true. It still executes the for loops until they're done, and only then does it test to see whether to leave the while loop. You'll need to solve that.
P.S. If you want to cheat, note that every Pythagorean triple has the form a = m2 - n2, b = 2mn, c = m2 + n2, for some m and n. You could actually get the answer without a computer, using algebra. But go ahead and finish the program you started--it's great practice.
As others have pointed out your variables a, b, c may not have been initialized by the time you get to System.out.println. There are several ways to avoid this.
Initialize variables explicitly, so:
int a = 0;
Use a do...while loop, which ensures your loop is run at least once, so:
do {
[...]
} while (!answerFound);
Use loop-scoped variables, which avoid local-scoped variables hanging around, so:
for (int a = 1; a <= 1000; a++) {
[...]
}
Let's say I have this Java code (midterm review!):
public class A {
public int key;
}
public class B extends A {
}
public class Problem1 {
public static void f(A x) {
A y = x;
y.key = x.key + 1;
}
public static void f(B x) {
B y = new B();
y.key = x.key + 2;
x = y;
}
public static void main(String[] args) {
A p = new A();
p.key = 3;
B q = new B();
q.key = 10;
f(p);
f(q);
p = q;
f(p);
System.out.println(p.key);
}
}
I'm not sure I properly understand p = q. Here's my understanding thus far: because B extends A, this operation is allowed but it doesn't make p and q point to the same object. Rather, it updates the key value for p but it remains of class A. Which is why f(p) at the end returns 11. This doesn't follow with what I thought I knew about Java previously so an explanation would be appreciated.
For example if I have int a = 4 and int b = 3, then I do:
a = b;
b++;
return a;
a will return 3, even though it should be pointing to the same thing that b is pointing to?
Please advise.
Think about it. The Java primitive holds the actual value in the memory byte area:
So if a = 4 and b = 3 , then a 8-byte machine memory area may hold it like (in binary)
a = 0 0 0 0 0 0 1 1
b = 0 0 0 0 0 0 1 0
Now, when you say a=b; means
a = 0 0 0 0 0 0 1 0
b = 0 0 0 0 0 0 1 0
Then b++ (i.e. b = b+1)
a = 0 0 0 0 0 0 1 0
b = 0 0 0 0 0 0 1 1
Then
return a;
Then a = 0 0 0 0 0 0 1 0 (i.e. 3)
Hope you understand it for a primitive value. Though for an object in java this is a different case altogether.
Now think, a and b are NOT primitive, rather object having a int field. A Sample class may look like
class Test {
private int value;
public Test(int value){
this.value = value;
}
public int getValue(){
return value;
}
public int increment(){
value++;
}
}
Then a = new Test(4); and b = new Test(3); is represented in memory like:
Heap:
a = x63489DF8 ---> [Test(4) Object, value = 4, Heap Memory address = x63489DF8]
b = xDFA78945 ---> [Test(3) Object, value = 3, Heap Memory address = xDFA78945]
(a and b holds a heap memory address which points to the objects)
Now, when you say a=b; means
a = xDFA78945 ---> [Test(3) Object value = 3, Heap Memory address = xDFA78945]
b = xDFA78945 ---> [Test(3) Object value = 3, Heap Memory address = xDFA78945]
(the object in memory address x63489DF8 is garbage collectible and a, b are referring to same object)
Now, say b.increment(); then the object in memory area xDFA78945 is manipulated and new object becomes [Test(3) Object value = 4, Heap Memory address = xDFA78945].
a = xDFA78945 ---> [Test(3) Object value = 4, Heap Memory address = xDFA78945]
b = xDFA78945 ---> [Test(3) Object value = 4, Heap Memory address = xDFA78945]
(Note that the change reflect both the reference, because both are actually pointing to the same object)
Now return a.getValue() returns 4.
(i.e. change done through reference b reflects back in reference a as well)
all variables are bit holders. ok
so if it is primitive type it will be holding bits which represent a bit lavel representation
of primitive .
a = b; b++; return a;
here bits representation of "3" is assigned to "a" so it is 3 now. but b still holding bits representing "3" so cange in b will stick to just "b"
now if a is a class variable and b also, in java variables always holds bit. when it is class
varible it hold the bits which represent the path to reach the class object which is living on heap. so when you do this a = b; a will also hold the path to reach the object which is living on heap . so "a" and "b" both holding path to same object.
if you change in property of "a"( change property of object which is reached by path which is holded by var "a") . will reflect in b. because these are pointing to same var.
For example if I have int a = 4 and int b = 3, then I do:
a = b;
b++;
return a;
a will return 3, even though it should be pointing to the same thing
that b is pointing to?
Primitives are handled as you'd expect them to. In other words, a will give the value 3 because it has taken up the numeric or bit value of b. However, you should look into autoboxing and immutability.
I'm not sure I properly understand p = q. Here's my understanding thus
far: because B extends A, this operation is allowed but it doesn't
make p and q point to the same object. Rather, it updates the key
value for p but it remains of class A.
With respect to objects, the operation p = q does actually assign p such that it "refers" (see link at bottom) to the same object as q. That's why approaches like defensive copying are necessary.
This also explains why modifications are taking place despite Java passing by value through the overloaded f methods. Parameter x remains as is, disappearing as soon as a process leaves the method scope, but the state of the referred object can be modified.
Here's a question that goes into the differences between C pointers and Java references.
https://softwareengineering.stackexchange.com/questions/141834/how-is-a-java-reference-different-from-a-c-pointer
I was asked to write a swap without using temp variables or using xor and i came up with this.
In Java, this works, but in C/C++ this does not work.
I was under the impression that this would always work since the value of 'a' on the left side of the '|' would be stored in a register and then the assignment to 'a' would occur negating the effect on the assigned value for 'b'.
int a = 5;
int b = -13;
b = a | (0 & (a = b));
You are modifying a variable and reading its value without an intervening sequence point.
b = a + 0 * (a = b);
// reading a's value modifying a
This is undefined behavior. You have no right to any expectations on what the code will do.
The C/C++ compiler optimizes the expression 0 * (a = b) to simply 0 which turns your code fragment into:
int a = 5;
int b = -13;
b = a;
In C/C++, assigment are performed in the order of expression. In Java, assignments occur last regardless of other expressions.
e.g. This increments in C but does nothing in Java.
a = a++;
i am trying some java code like this
class Test {
public static void main (String [] args){
byte b = 10;
b = b + 10;
}
}
after saving when i tried to compile it , it is giving me an error
D:\java\Test.java:4: possible loss of precision
found : int
required: byte
b = b + 10;
^
1 error
but there is no if try something like this
b++;
b+=10;
it is perfectly alright
what is reason for this ?
You have to write your original code as
b = (byte)(b + 10);
The problem is that b + 10 is of type int, as the byte is widened to an int.
The reason for this is that there is a conceptual ambiguity, if b was, say, 120. Is then b+10 equal to 130, or is it equal to -126?
Java designers decided that addition should be carried out in int in this case, so that 120+10 is 130. Then it can't be stored into a byte.
For b+=10, it's clear that you want to modify b, so it's a byte addition.
Well it says possible loss of precision because compiler thinks that may be after adding 10 to b it may go over limit of byte size, but as you use b++ or b+=10 its not just adding 10 but also typcasting it automatically so as to confirm at compiler level that the value of b does not go beyond limits of byte size.