• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 317
  • Last Modified:

Increment & Decrement operators

Why does Increment & Drecement operators behave differently on different operating systems.Why is it very unpredictable?
0
Ramprasad_Inala
Asked:
Ramprasad_Inala
  • 7
  • 3
  • 3
  • +9
1 Solution
 
Ramprasad_InalaAuthor Commented:
Adjusted points from 50 to 75
0
 
rbrCommented:
What differences to you get?
I don't know any (if you take care of the overflow since an integer isn't the same size on different OSs)
0
 
makerpCommented:
things such as

i++ and ++i do not always resolve the same depending on platform/os

What differences to you get?
 

 
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
rbrCommented:
If i++ and ++i do not always resolve the same depending on platform/os you are doing something not defined or your compiler has a bug.
0
 
rbrCommented:
e.g.


i=1;


printf ("%d,%d,%d",i++,i++,i++);

would lead to different results for different compilers and options.
0
 
makerpCommented:
oh i just read it the other day in a book called .. wait for it

'industrial strength C++'

if thats wrong then well theres no hope for any one

:)
0
 
guyssCommented:
well, the problem occurs because you use
the ++ operator more than once in the same command, and ANSI does NOT define
what should happen first, these things are usually easily resolved by the programmer, simply write good code, and you won't have these problems.
0
 
pjknibbsCommented:
So long as you only ever use one on a line they should behave the same way between systems. When you start doing the multiple ++s, as in rbr's example, you start running into problems of which order your C compiler carries out the operations--this is not set out in the standard C specification, so compiler vendors are free to pick whatever suits them best. For the same reason you shouldn't really do things like:

if (c != NULL and *c == 400)

because not all compilers will evaluate the test for NULL before the second part of the if, and dereferencing a NULL pointer is almost always fatal.
0
 
rbrCommented:
To guyss: You are not correct. It is not the number of the ++ operaters since


printf ("%d,%d",i++,i); could lead to differnt reults too. The way how arguments are evaluated is not defined in C in general.

But I agree with your second statement.
0
 
guyssCommented:
you're right, of course...
wasn't thinking right...
my mistake.
0
 
rbrCommented:
To pjknibbs: Your are wrong too. Pls read
http://www.eskimo.com/~scs/C-faq/q3.8.html
0
 
pjknibbsCommented:
rbr: I don't see how the article you point out invalidates what I said--it merely said everything within two sequence points would be evaluated, *not* which order the sequence points would be evaluated in.
0
 
ozoCommented:
It does not say everything within two sequence points would be evaluated, it says that if an object is modified between sequence points, it can only be accessed in order to determine the value for that modification.
i.e. printf ("%d,%d",i++,i); is undefined, since i is modified by the i++, but the access in the second ,i is not for the purpose of determining that modified value.
This applies to all side effects, not just ++ and -- operators.
0
 
mathoughtCommented:
I am afraid the unary operator ++ do have different implementation in different platforms. For example:

int *p;
p++;

Under some platforms (like DOS real mode) the size of a pointer is different than in others (like win32) thus ++ will have different effect.
0
 
guyssCommented:
not as far as the language is concerned,
as long as you're pointing to C structures, you're ok,
if you need to calculate addresses,
use sizeof directly, and not the ++ operator.
0
 
rbrCommented:
To Ramprasad_Inala: Pls give any feedback. We will not be able to help you.
0
 
PacmanCommented:
Ramprasad,

increment operator is same as "+= 1" which is same as " x = x + 1"

you say that
x = x + 1
behaves differently on different OS ?

I can't believe that.

0
 
NamitaCommented:
There is no difference. They behave same on all OS.

It has a higher precedence always on all Operators but they are compiler dependent.





 

0
 
sreenathkCommented:
The statement itself is a ambiguous statement and should not be used in programing. You are correct that the behaviour is different on diff. os. Becauase some Os starts execution from the last parameter and some from the first.

Sreenath
0
 
KangaRooCommented:
Despite the fact that the actual code with the problem is not given, the answer is given before, the order of evaluation with multiple increments between two sequence points is likely the problem, as rbr pointed out. There is nothing undefined about operator++ itself.

>> if (c != NULL and *c == 400)
To the best of my knowledge, first c!=NULL is evaluated anf *c==400 is only evalauted if c!=NULL. Guaranteed.
0
 
rbrCommented:
Pls give some feedback !!!
0
 
ozoCommented:
>> if (c != NULL and *c == 400)
 depends on whether you've
#define and &
 or
#define and &&
0
 
ozoCommented:
I don't see any
#include <iso646.h>
in the above code
0
 
alexoCommented:
>> int *p;
>> p++;

The above code sequence modifies p to point to the next int.  It is the same as
  p = (int*)((char*)p + sizeof(int));

The "problem" is that sizeof(int) is implementation defined.


>> depends on whether you've [...]

Ozo!  Really!!!

  /* iso646.h standard header */
  #ifndef _ISO646
  #define _ISO646
  #define and            &&
  #define and_eq      &=
  #define bitand      &
  #define bitor            |
  #define compl      ~
  #define not            !
  #define not_eq      !=
  #define or            ||
  #define or_eq      |=
  #define xor            ^
  #define xor_eq      ^=
  #endif /* _ISO646 */
0
 
alexoCommented:
I don't see any int main() either.

If you were able to comment on my remark 17 minutes before it was posted, surely your amazing powers of prescience tell you that <iso646.h> will be #included sometime in the future.
0
 
KangaRooCommented:
'and' what about section 2.5??
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 7
  • 3
  • 3
  • +9
Tackle projects and never again get stuck behind a technical roadblock.
Join Now