Why there is difference in outputs when i change the compiler?
-
CODE: int k = 35; printf( "%d %d %d", k == 35, k = 50, k > 40 ); When i compiled same code in Turbo C++ then its giving output as: 0 50 0 and in Microsoft VC++ its giving output as: 0 50 1 Can anyone tell me why there is difference in outputs when i change the compiler? Thanks Nilesh
-
CODE: int k = 35; printf( "%d %d %d", k == 35, k = 50, k > 40 ); When i compiled same code in Turbo C++ then its giving output as: 0 50 0 and in Microsoft VC++ its giving output as: 0 50 1 Can anyone tell me why there is difference in outputs when i change the compiler? Thanks Nilesh
Different compilers might -and will- interpret the code differently, don't be surprised at this because either some compilers follow standards, some don't, ot they interpret them differently, or the standard itself does not specify every possible aspect of a given problem so the guys making the compiler are free to handle it as they see fit. Based on your code sniplet, i'd say that the Turbo C version will "run" from right to left, so: k > 40 -> 0, since k is at this point 35 which is less than 40 k = 50 -> 50, since k is 50 k == 35 -> 0, sinke k is 50 which is not 35 While the MS compiler is probably doing it in this order: k = 50 -> 50, makes k 50 at first k == 35 -> 0, since k is 50, not 35 k > 40 -> 1 since k is 50 which is greater than 40 There might be other explanations too i guess.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
-
Different compilers might -and will- interpret the code differently, don't be surprised at this because either some compilers follow standards, some don't, ot they interpret them differently, or the standard itself does not specify every possible aspect of a given problem so the guys making the compiler are free to handle it as they see fit. Based on your code sniplet, i'd say that the Turbo C version will "run" from right to left, so: k > 40 -> 0, since k is at this point 35 which is less than 40 k = 50 -> 50, since k is 50 k == 35 -> 0, sinke k is 50 which is not 35 While the MS compiler is probably doing it in this order: k = 50 -> 50, makes k 50 at first k == 35 -> 0, since k is 50, not 35 k > 40 -> 1 since k is 50 which is greater than 40 There might be other explanations too i guess.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
Thanks Code-o-mat for your explanation. But it means that there are no standard rules for compilers to interpret the code. Am i correct?
-
Thanks Code-o-mat for your explanation. But it means that there are no standard rules for compilers to interpret the code. Am i correct?
Well, there!s the ANSI C Standard[^] that i know of, but as said, some things the standard specifies as "undefined", which means -as i said- that different compilers might and will behave differently in case they "meet" something the standard does not clearly have an "oppinion" about. Your best bet to avoid such problems is to try and write code that avoids these and write "obvious" code. For example, depending on what you need you could do:
...
k = 50;
printf("%d, %d, %d", k == 35, k, k > 40);or
int a = (k == 35);
k = 50;
int b = k;
int c = (k > 40);
printf("%d, %d, %d", a, b, c);and so on...
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
-
Thanks Code-o-mat for your explanation. But it means that there are no standard rules for compilers to interpret the code. Am i correct?
Correct. There are holes in the definition of the C language. IIRC the official specification even holds an appendix with issues that the compiler designer has to solve, and has to publish how he did solve them. One of those issues is the order in which side effects may occur, e.g. does
i=i++;modify i or not? Your defense against such things is very easy: 1) don't create statements that are ambiguous. In your example, split the line in a couple of lines and use temporary variables, so the parameters get evaluated in the order you choose. 2) or switch to an unambiguous language, such as Java and C# :)Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages