This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi! I found this on one of the mock exams. After the following code is run, the output is 10,0,20 and that is also supposed the be the right answer. But i think the answer should be 10, 0, 30. Can somebody explain what really happens to the value of v.i, in detail ?
Originally posted by Parag Kale: Hi! I found this on one of the mock exams. After the following code is run, the output is 10,0,20 and that is also supposed the be the right answer. But i think the answer should be 10, 0, 30. Can somebody explain what really happens to the value of v.i, in detail ?
Parag, You have to walk through it carefully you'll get tripped up. I think here's what's confusing you: When the method amethod() calls the another() method, it is sending a reference to the v (ValHold) object. The first thing another() does is reset i to 20. It is resetting the original object's value since it only passed a reference to the object, not the object itself nor a copy of the object. If you read the Campfire's "Cup Size" essay, you'll see my point. Following that logic through, you'll see that i is really 20 when it is finally printed out at the end of amethod(). [This message has been edited by Rebecca Pickett (edited April 10, 2001).]
Note that over in another(), you're monkeying with a copy of v, even though it refers to the same object that the original v refers to. when you get back to aMethod(), you've still got that original v waitin' there still referring to the original ValHold object. Umm.. also note the coding conventions in the chicken coop to make your code look spiffy like above!
Joined: Apr 08, 2001
OK...i got it now.I needed to think THAT way. About the code part, i'll remember that. Promise clean code the next time. Thanx a bunch. Cheers, Parag