Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Q about increment and assignment

Reply
Thread Tools

Q about increment and assignment

 
 
John W. Kennedy
Guest
Posts: n/a
 
      12-24-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi, this is not gonna work like you write it. Look if you do i = i++;
> it will asign i = i because it evaluates i and after that it
> increments.


You are right about the result, as far as it goes, but why are you
giving a confusing and imprecise explanation after two of us have given
exact descriptions?

> You should do:
>
> i = ++i;


No, he shouldn't. It's true that this statement works, but it's stupid.
The correct statement is:

++i;

or

i++;

(I personally prefer the first, but the second is more common in the wild.)

And don't top-post.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
 
Reply With Quote
 
 
 
 
Luc The Perverse
Guest
Posts: n/a
 
      12-24-2006
"Big D" <(E-Mail Removed)> wrote in message
news:Xns98A2B1DDE97D3supagoatatverizonDne@216.196. 97.142...
> I'm confused by the output of the following code:
>
> public class PP {
> public static void main(String[] args) {
> int i = 1;
> i = i++;
> System.out.println(i);
> }
> }
>
> It outputs 1.
>
> I understand the assignment operator happening before the ++, but I don't
> understand why the ++ doesn't increment. I thought the statement should
> basically expand to:
>
> i = i;
> i = i+1;
>
> but the ++ gets lots somewhere...



Yes

++ is a function, which does two things - returns a value, and changes the
variable.

i=i++;
the function i++ must be calculated first before the final assignment is
completed.

i= (i++);

i++ returns i, so you can reduce it to

i=i;

In other words, the ++ is not being lost, it is just being overwritten.

int i = 1;
i = i++;

is the same as writing

int i = 1;
int oldval = i;
i = i + 1;
i = oldval;

--
LTP




 
Reply With Quote
 
 
 
 
Luc The Perverse
Guest
Posts: n/a
 
      12-24-2006
"John W. Kennedy" <(E-Mail Removed)> wrote in message
news:B%njh.230$(E-Mail Removed)...
> No, he shouldn't. It's true that this statement works, but it's stupid.
> The correct statement is:
>
> ++i;
>
> or
>
> i++;


He didn't write either of them

He was trying to understand part of a test which deliberately used operators
in an unusual way to test one's understanding. The practicality of such a
test, or the implications on actual programming ability are questionable.
But it should suffice to eliminate those completely inept.

--
LTP




 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      12-24-2006

"Stefan Ram" <(E-Mail Removed)-berlin.de> wrote in message
news:(E-Mail Removed)-berlin.de...
> "Mike Schilling" <(E-Mail Removed)> writes:
>>I'll have to make that an interview question. If you answer anything
>>other
>>than "I would *never* write code like that", you wouldn't get the job.

>
> Such code might make perfect sense, for example, as part of a
> Java compiler test suite.


As it happens, I don't hire Java compiler writers. For the usual purposes
of code writing (to implement algorithms), there's no excuse for writing
code whose meaning is that obscure, any more than there's an excuse for

int sum(int []arr)
{
int sum = 0;
int i = 0;
try {
while(true) {
sum += arr[i++];
} catch (ArrayIndexOutOfBoundsException ex) {
return sum;
}
}


 
Reply With Quote
 
John Ersatznom
Guest
Posts: n/a
 
      12-24-2006
Karl Uppiano wrote:
> That is a Good Thing(TM). I'm not disputing that. But I doubt I could quote
> chapter and verse from the JLS off the top of my head. I'm an open-book-test
> kind of guy (it's how the real world works anyway. No employer I know of
> would require you to work without access to any kind of reference
> materials). I'm just sayin'...


Agreed. In fact, if you're even thinking of reaching for an official
specification or asking a language lawyer to be sure of what some code
will do, it's a sign that the code in question is excessively obscure
and should be rewritten to be more self-documenting.

If I were giving a job interview, and I did include code like that on
it, the best answer I would be looking for from a potential hire would
be "I don't know for sure, but I wouldn't write code like that anyway,
and I'd hope to hell anyone who did would document it for me."
 
Reply With Quote
 
Big D
Guest
Posts: n/a
 
      12-24-2006
Thanks for the explanation, all. Obviously the temporary variable was the
key to this caper.
 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      12-24-2006
John Ersatznom wrote:
> Karl Uppiano wrote:
>> That is a Good Thing(TM). I'm not disputing that. But I doubt I could
>> quote chapter and verse from the JLS off the top of my head. I'm an
>> open-book-test kind of guy (it's how the real world works anyway. No
>> employer I know of would require you to work without access to any
>> kind of reference materials). I'm just sayin'...

>
> Agreed. In fact, if you're even thinking of reaching for an official
> specification or asking a language lawyer to be sure of what some code
> will do, it's a sign that the code in question is excessively obscure
> and should be rewritten to be more self-documenting.
>
> If I were giving a job interview, and I did include code like that on
> it, the best answer I would be looking for from a potential hire would
> be "I don't know for sure, but I wouldn't write code like that anyway,
> and I'd hope to hell anyone who did would document it for me."


Oh well, that's one job I would never get. Personally, I think knowing
exactly what statements with multiple side effects do is useful, because
it makes it easier to replace them with functionally equivalent but more
readable code. It's not as though the Java model of ++ and -- is in any
way messy, unmemorable, or difficult to understand.

Patricia
 
Reply With Quote
 
John Ersatznom
Guest
Posts: n/a
 
      12-24-2006
Patricia Shanahan wrote:
>> If I were giving a job interview, and I did include code like that on
>> it, the best answer I would be looking for from a potential hire would
>> be "I don't know for sure, but I wouldn't write code like that anyway,
>> and I'd hope to hell anyone who did would document it for me."

>
> Oh well, that's one job I would never get. Personally, I think knowing
> exactly what statements with multiple side effects do is useful, because
> it makes it easier to replace them with functionally equivalent but more
> readable code. It's not as though the Java model of ++ and -- is in any
> way messy, unmemorable, or difficult to understand.


It's the "I wouldn't write code like that anyway" part I'd consider most
important. If you could clean up code like that written by someone else,
so much the better, especially if you could do it even when the "someone
else" hadn't documented it.
 
Reply With Quote
 
jupiter
Guest
Posts: n/a
 
      12-24-2006

"John W. Kennedy" <(E-Mail Removed)> wrote in message
news:c0ijh.1967$(E-Mail Removed)...
> Big D wrote:
>> I'm confused by the output of the following code:
>>
>> public class PP {
>> public static void main(String[] args) {
>> int i = 1;
>> i = i++;
>> System.out.println(i);
>> }
>> }
>>
>> It outputs 1.
>>
>> I understand the assignment operator happening before the ++,
>> but I don't understand why the ++ doesn't increment. I thought
>> the statement should basically expand to:
>>
>> i = i;
>> i = i+1;
>>
>> but the ++ gets lots somewhere...

>
> No, it gets expanded into:
>
> t = i;


John, is t a copy of the bits in i made by the postfix ++ method?

> i = i + 1;
> i = t;


Is it fair then to say that t gets restored because of the way the
postfix operator applies only after the expression is evaluated?

What is the difference between the original problem and this one?

int i=1;
System.out.println("i=" + i++); //output=1
System.out.println("i=" + i);//output=2

I find this one easier to understand because eventually the new
bits do output. They don't get overwritten. In the original problem
there is overwriting going on that cause the 2 value to be lost
entirely. Is this due to the self-referencing aspect of the
original problem i=i++;?

One last question: Where is that temp copy of the bits visible? I
can't see it in a debugger, so maybe I'm not using it (Eclipse) to
great advantage. I see the original i bits on the stack and that's
about it. This should not involve heap storage, so that leaves me
wondering where/how I'd ever see that temp set of bits.

thanks ...






 
Reply With Quote
 
John W. Kennedy
Guest
Posts: n/a
 
      12-24-2006
jupiter wrote:
> "John W. Kennedy" <(E-Mail Removed)> wrote in message
> news:c0ijh.1967$(E-Mail Removed)...
>> Big D wrote:
>>> I'm confused by the output of the following code:
>>>
>>> public class PP {
>>> public static void main(String[] args) {
>>> int i = 1;
>>> i = i++;
>>> System.out.println(i);
>>> }
>>> }
>>>
>>> It outputs 1.
>>>
>>> I understand the assignment operator happening before the ++,
>>> but I don't understand why the ++ doesn't increment. I thought
>>> the statement should basically expand to:
>>>
>>> i = i;
>>> i = i+1;
>>>
>>> but the ++ gets lots somewhere...

>> No, it gets expanded into:
>>
>> t = i;

>
> John, is t a copy of the bits in i made by the postfix ++ method?


For explanatory purposes, I've eliminated the ++ altogether.

>> i = i + 1;
>> i = t;


> Is it fair then to say that t gets restored because of the way the
> postfix operator applies only after the expression is evaluated?


My t does not exist in the postfix version at all, so in one sense the
question is meaningless, but yes, I guess you could say so.

> What is the difference between the original problem and this one?


> int i=1;
> System.out.println("i=" + i++); //output=1
> System.out.println("i=" + i);//output=2


It doesn't have the expression "i = i++", which is bad coding, though
technically legal.

> I find this one easier to understand because eventually the new
> bits do output. They don't get overwritten. In the original problem
> there is overwriting going on that cause the 2 value to be lost
> entirely. Is this due to the self-referencing aspect of the
> original problem i=i++;?


Yes, that's the key.

> One last question: Where is that temp copy of the bits visible? I
> can't see it in a debugger, so maybe I'm not using it (Eclipse) to
> great advantage. I see the original i bits on the stack and that's
> about it. This should not involve heap storage, so that leaves me
> wondering where/how I'd ever see that temp set of bits.


It isn't visible at the Java level, though it will be seen in the
bytecode (does Eclipse have an option to trace at the bytecode level?
I've never had occasion to try). But "i=i++" is bad, evil, wicked,
perverse, satanic, blood-sucking, kitten-murdering, baby-raping,
Bush-voting malpractice, so Just Don't Do It.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Post increment ++ has higher precedence than pre increment ++. Why? Alf P. Steinbach /Usenet C++ 0 05-22-2011 12:03 PM
why prefix increment is faster than postfix increment? jrefactors@hotmail.com C++ 99 06-11-2010 12:51 PM
post increment or pre increment? Peng Yu Perl Misc 7 11-23-2008 11:44 PM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
why prefix increment is faster than postfix increment? jrefactors@hotmail.com C Programming 104 10-27-2005 11:44 PM



Advertisments