How does the post increment work really?

[Maulin Vasavada]

Hi all,

I have a code issue and I have a below question for the same.

Assuming data[] is of type byte[], is the below statement in java -

while((data[p++] & 0x80) == 0x80);

same as -

while ( (data[p] & 0x80) == 0x80 ) { p++; }

?

I tried with

do { p++; } while ( (data[p] & 0x80)  == 0x80 );

That also doesn't seem to be the same thing. I am not putting code around this but essentially if I make this change for not using data[p++] code stops working! (This is the only change that is breaking the code).

Thanks
Maulin

[Winston Gutkowski]

Maulin Vasavada wrote:Assuming data[] is of type byte[], is the below statement in java - [...] - same as - [...]?

No; in the first case p will be 1 greater than the point at which the mismatch was found after you exit the loop; and I would expect BOTH to fail with an ArrayIndexOutOfBoundsException unless you add a check for length.

Question: Why not just use:

for (p = 0; p < data.length && (data[p] & 0x80) == 0x80; p++) {}

or indeed:

int p = 0;
for (byte value : data) {
   if ((value & 0x80) != 0x80 )
      break;
   p++;
}

Both seem rather clearer than what you've got. And the problem isn't really anything to do with post-increment; it's to do with the fact that you're cramming an awful lot of logic into a single statement when you don't need to.

Write Dumb Code.

Winston

PS: You do realise that '(data[p] & 0x80) == 0x80' is just a long-winded way of saying 'data[p] < 0', don't you?

[Maulin Vasavada]

Hi Winston

I completely agree to your comments about why we have to re-write the same logic in better way.

I am refactoring the code and I ran into this. I will try options you suggested and post the findings.

Thanks
Maulin

[Maulin Vasavada]

Okay, I fixed the code as below and now it works,

while ( (data[p] & 0x80) == 0x80 ) {
						p++;
					} 
					// Step forward by one more
					p++;

Thanks
Maulin

[Campbell Ritchie]

Please tell us what the condition in () after while means. You may wish to crib the answer from Winston't post

[Winston Gutkowski]

Maulin Vasavada wrote:Okay, I fixed the code as below and now it works...

Hmmm. Seems an odd way to go. I'm particularly interested in the "Step forward by one more" increment, because that will put you at the index after the mismatch. So if, for example, you found a mismatch at index 3, that will set it to 4, which seems like a strange requirement.

However, if it works, don't fix it.

Winston

PS: I still don't see any check for length.

[Maulin Vasavada]

Hi Winston

We do have the length check somewhere before this code and this code is a specific parsing logic for a specific data standard we have. For the purpose of this thread we can just focus on 'technical' aspect of why earlier it didn't work for me (after my code change) is ,

1. The post increment in the original code was happening even when while condition didn't match. So to you point it IS going one pointer ahead than the actual mismatch point ('why' part of this we will blame on the 'specific' parsing logic )
2. To fix that I added one more p++ after the while loop after my change


Thanks
Maulin

[Winston Gutkowski]

Maulin Vasavada wrote:1. The post increment in the original code was happening even when while condition didn't match. So to you point it IS going one pointer ahead than the actual mismatch point ('why' part of this we will blame on the 'specific' parsing logic )
2. To fix that I added one more p++ after the while loop after my change...

In which case, I suspect it's wrong, and you just haven't discovered when yet. I could be wrong, but those first loops you listed suggest not.

The loop will only exit when there is a MISmatch, at which point p will hold the index at which it occurred. It seems a very strange thing to then increment the index again (without a length check) to get the index after that.

However, if that's the way it works and you can understand it, don't let me stop you.

Winston