C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  ambiguity of post-increment and post-decrement Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Mark Turney Guest Posted: Thu Dec 11, 2003 11:39 am    Post subject: ambiguity of post-increment and post-decrement I was reading "Practical C++ Programming" yesterday, and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. I tested with the VC6 compiler and the gnu compiler, but with the same results: the post-decrement occurs after the entire statement is executed, not during it's execution. I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order (regardless of what occurs during compilation with different compiler makers). I am still in the process of working my way through C++ and I don't have a copy of the official standard, so I was hoping a more learned individual would be able to elucidate this troublesome issue for me. "Pracitcal C++ Programming" recommends against the use of increment and decrement operators within statements, but I've learned to really enjoy them. Thanks for the help -mark [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Antoun Kanawati Guest Posted: Thu Dec 11, 2003 8:42 pm    Post subject: Re: ambiguity of post-increment and post-decrement Mark Turney wrote: Quote: I was reading "Practical C++ Programming" yesterday, and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. I tested with the VC6 compiler and the gnu compiler, but with the same results: the post-decrement occurs after the entire statement is executed, not during it's execution. The problem is that "a[i] = i++" has no sequence points. So, the compiler is free to do it in any order, e.g.: int t = i; i = i + 1; a[i] = t; or a[i] = i; i = i + 1; Since both options are valid, you cannot expect that such a code snippet will always compile in this manner under all possible optimization flags in all contexts. So, in short words, you have a snippet of code that has two possible meanings, and this is a serious problem. The example distills the issue. In practice, instances of such misuse may occur in larger more complex expressions, where the ambiguity is quite real. The standard is not "ambiguous" about these issues: it defines sequence points, and specifically declines to define evaluation order between sequence points. Overspecification of order between sequence points complicates code generation, eliminates optimization opportunities, lowers the abstraction level, and is generally not a "good thing". In particular, think of function calls, and argument layout on the stack for different calling conventions (C, Pascal, Fortran, etc...) that your C++ code may have to interface with. As for the recommendation in the book: in practice, an expression that has such subexpressions is harder to read, and trickier to debug than one that doesn't; particularly when the ternary operator is involved, e.g.: foo = i++ + j++ + (foo ? y++ : b); Look at that, and try to figure out the following: 1. When will y++ execute? 2. Should the y++ be replaced with a y, and a y++ after the statement? [i.e.: is this a sloppy maintenance edit that introduced the ternary operator?] Given a little piece of code like this, and a malfunctionning program, this can be frustrating. The problem with the ++/-- and the ternary operators is that they compress a lot of semantics into very little textual space, giving minor changes to program text a lot of impact on the semantics of the code, which increases the chance that a programmer will miss or misinterpret a fine point. As for the "urge" and "desire" to use these operators: every C/C++ programmer goes through a phase where they find ++/--/+=/*=/?:/... very sexy, and where they expend significant efforts to use them to condense their code. After a few maintenace cycles on your own code, and some on other people's code, the urge will pass. Quote: I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order (regardless of what occurs during compilation with different compiler makers). I am still in the process of working my way through C++ and I don't have a copy of the official standard, so I was hoping a more learned individual would be able to elucidate this troublesome issue for me. "Pracitcal C++ Programming" recommends against the use of increment and decrement operators within statements, but I've learned to really enjoy them. Thanks for the help -mark [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andrew Koenig Guest Posted: Thu Dec 11, 2003 9:14 pm    Post subject: Re: ambiguity of post-increment and post-decrement Quote: I was reading "Practical C++ Programming" yesterday, and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. You should be confused, because the claim you're saying the book makes isn't true. Although I am not familiar Pre-increment must finish the increment before it yields its result, because otherwise it doesn't know what result to yield. Post-increment must finish the increment before the next sequence point. In all cases, it is prohibited to write (i.e. modify) a variable twice between sequence points, or to read and write it between sequence points unless it is being read in order to determine the value to write. This prohibition has nothing to do with increment operators. Quote: An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. This example is illegal, because it reads and writes i between sequence points. Specifically, it reads i as part of the expression a[i] and writes it as part of the expression i++. Quote: I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order (regardless of what occurs during compilation with different compiler makers). Who told you? You may wish to question further advice from this source. Quote: I am still in the process of working my way through C++ and I don't have a copy of the official standard, so I was hoping a more learned individual would be able to elucidate this troublesome issue for me. "Pracitcal C++ Programming" recommends against the use of increment and decrement operators within statements, but I've learned to really enjoy them. A quick rule of thumb: There's no problem in using increment and decrement operators within statements, provided that the variable being incremented or decremented appears nowhere else in that statement. This rule does not cover all cases, but hits enough of the common ones to be useful. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Thu Dec 11, 2003 9:16 pm    Post subject: Re: ambiguity of post-increment and post-decrement In article <ec18a62c.0312101029.2179a257 (AT) posting (DOT) google.com>, Mark Turney <google (AT) freelance3d (DOT) com> writes Quote: I was reading "Practical C++ Programming" yesterday, Please go and read the reviews of both the first and second editions http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0ti_p&file=p001010a http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0ti_p&file=p003432a I think you will then understand that questions arising from a study of this book are likely to be answered with 'the author is wrong.' Quote: and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. Actually the author would have to be wrong because it will always be undefined behaviour to apply both a pre and post increment to an lvalue in a single expression. Quote: An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. Here again we have an error because i is both read for use and accessed for the purpose of determining the value to be written to it without an intervening sequence point. Such code will always have undefined behaviour (i.e. it can do anything the compiler decides it wishes to do.) Quote: I tested with the VC6 compiler and the gnu compiler, but with the same results: the post-decrement occurs after the entire statement is executed, not during it's execution. So? Undefined behaviour can include meeting your expectations, it just isn't required to do so. Quote: I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order (regardless of what occurs during compilation with different compiler makers). In general C++ (like C before it) imposes no constraints to order of evaluation of sub expressions (though it does place some requirements on the order of evaluation of operators) other than that a sub-expression must be evaluated not later than the time when its value is required for use. Quote: I am still in the process of working my way through C++ and I don't have a copy of the official standard, so I was hoping a more learned individual would be able to elucidate this troublesome issue for me. "Pracitcal C++ Programming" recommends against the use of increment and decrement operators within statements, but I've learned to really enjoy them. Please buy a different book. The one you have will only teach you many things that are untrue. If you can already program I would suggest you start with Accelerated C++ by Koenig & Moo. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Thu Dec 11, 2003 9:19 pm    Post subject: Re: ambiguity of post-increment and post-decrement Mark Turney wrote: Quote: I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order Good Lord! The most frequent of the FAQs returns again. I really wish we would just adopt Java's defined execution order and have done with this decades-old idiocy. OP, this question is as old as the hills. The same undefined behavior exists in C, so it's been around for some 25 years. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Thu Dec 11, 2003 9:26 pm    Post subject: Re: ambiguity of post-increment and post-decrement Mark Turney wrote: Quote: I was reading "Practical C++ Programming" yesterday, Please do not take that book too seriously. It is very much stuck in the past and its advice seems to be mostly concerned with avoiding bugs in circa-1990 compilers. Quote: and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. On this point, it is correct. Order of evaluation is generally unspecified, though it is restricted by sequence points introduced by function calls and various operators. Quote: An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. snip This results in undefined behaviour. Please see <http://www.eskimo.com/~scs/C-faq/s3.html>. That is a FAQ for C but the same issues exist in C++. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Potter Guest Posted: Fri Dec 12, 2003 9:32 am    Post subject: Re: ambiguity of post-increment and post-decrement On 11 Dec 2003 06:39:09 -0500, [email]google (AT) freelance3d (DOT) com[/email] (Mark Turney) wrote: Quote: I was reading "Practical C++ Programming" yesterday, and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. They both sound wrong. The value of the post-increment expression is the old value of the operand regardless of when the new value is stored in the operand. Quote: An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. The problem is using i more than once in the statement, not any ambiguity in the postfix increment. Possible translations assuming that i is of type int. int tmp(i); i = i + 1; a[i] = tmp; a[i] = i; i = i + 1; In the second translation, i is both incremented and has its old value accessed. Whenever any of the possible translations attempts to access the old value for a purpose other than to determine the new value, there is undefined behavior. That means that executing the statement can do anything. Consider a slightly worse statement, i = i++, which has been pronounced i gets i double cross. John [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Potter Guest Posted: Fri Dec 12, 2003 9:53 am    Post subject: Re: ambiguity of post-increment and post-decrement On 11 Dec 2003 15:42:48 -0500, Antoun Kanawati <anotunk (AT) comcast (DOT) net> wrote: Quote: As for the recommendation in the book: in practice, an expression that has such subexpressions is harder to read, and trickier to debug than one that doesn't; particularly when the ternary operator is involved, e.g.: Likely true. Quote: foo = i++ + j++ + (foo ? y++ : b); However, this one is well defined. Quote: Look at that, and try to figure out the following: 1. When will y++ execute? Whenever foo has a non-zero value at the sequence point prior to this statement. Quote: 2. Should the y++ be replaced with a y, and a y++ after the statement? [i.e.: is this a sloppy maintenance edit that introduced the ternary operator?] Red herring. If the code is wrong, it makes no difference how it is written. Assuming that the code is correct we could debate whether the following is better. if (foo == 0) { foo = y; y = y + 1; } else foo = b; foo = foo + i; i = i + 1; foo = foo + j; j = j + 1; Nonsense usually looks like nonsense no matter how it is written. John [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Dec 12, 2003 4:26 pm    Post subject: Re: ambiguity of post-increment and post-decrement In article <1071153311.127514 (AT) master (DOT) nyc.kbcfp.com>, Hyman Rosen <hyrosen (AT) mail (DOT) com> writes Quote: Mark Turney wrote: I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order Good Lord! The most frequent of the FAQs returns again. I really wish we would just adopt Java's defined execution order and have done with this decades-old idiocy. OP, this question is as old as the hills. The same undefined behavior exists in C, so it's been around for some 25 years. But it isn't undefined behaviour, it is unspecified behaviour which is not the same thing at all. Actually changing to a Java like rule should be possible because it only requires something become specified. However the compiler implementers would have to handle the problem. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit or http://www.robinton.demon.co.uk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Dec 12, 2003 4:28 pm    Post subject: Re: ambiguity of post-increment and post-decrement In article <slrnbth762.1ko.do-not-spam-benh (AT) tin (DOT) bwsint.com>, Ben Hutchings <do-not-spam-benh (AT) buswebsoft (DOT) dnsalias.com> writes Quote: and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. On this point, it is correct. No it isn't, it is free to update the variable at any time before the next sequence point, all that is required for post increment/decrement is that the old value is used in evaluating the sub-expression that contains the post increment/decrement operator. It is because of this freedom that the other rule about not reading a variable that will be modified a second time exists. Practical C++ is littered with places where the author uses his own mental model of how C++ works rather than using the one specified by the Standard. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit or http://www.robinton.demon.co.uk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Severin Ecker Guest Posted: Sat Dec 13, 2003 2:03 am    Post subject: Re: ambiguity of post-increment and post-decrement hi! Quote: A quick rule of thumb: There's no problem in using increment and decrement operators within statements, provided that the variable being incremented or decremented appears nowhere else in that statement. This rule does not cover all cases, but hits enough of the common ones to be useful. could you please give a quick example of where the rule doesn't hold? perhaps when using in different branches of the ?: operator? foo = x ? i++ : a[i]; i can't think of any other example.. that would be very kind of you. thanks & regards, sev [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Sat Dec 13, 2003 2:06 am    Post subject: Re: ambiguity of post-increment and post-decrement "Andrew Koenig" <ark (AT) acm (DOT) org> wrote Quote: I was reading "Practical C++ Programming" yesterday, and it mentioned that the order of execution for post-increment and post-decrement operators was ambiguous. I had previously learned that a post-increment or post-decrement operator modifies the operand once the entire statement has been executed, not during execution of the statement, so this confused me. You should be confused, because the claim you're saying the book makes isn't true. Although I am not familiar It looks like something is missing here. From his phrasing, I'm not sure what the book actually claims, but it does seem to be saying something to the effect that the exact moment when the side effect of modifying the variable takes place is not specified by the standard, which is correct as far as it goes. (Saying that the operator itself is "ambiguous" is more than a little ambiguous itself.) Quote: Pre-increment must finish the increment before it yields its result, because otherwise it doesn't know what result to yield. Sort of. Obviously, pre-increment must know the value to "return" before that value is used, but there is no requirement that the side effect of modifying the original lvalue have taken place. (I know you know this, but I think it possible to put more into your statement than you meant.) Quote: Post-increment must finish the increment before the next sequence point. In all cases, it is prohibited to write (i.e. modify) a variable twice between sequence points, or to read and write it between sequence points unless it is being read in order to determine the value to write. This prohibition has nothing to do with increment operators. An examples given to illustrate the ambiguity is: a[i] = i++; // may increment i before or after a[i] is evaluated. This example is illegal, because it reads and writes i between sequence points. Specifically, it reads i as part of the expression a[i] and writes it as part of the expression i++. I have now been told that the actual ANSI C++ Standard is ambiguous concerning execution order (regardless of what occurs during compilation with different compiler makers). Who told you? You may wish to question further advice from this source. I think he is just misusing a word. The actual standard isn't at all ambiguous here -- it very clearly says that the execution order is not specified. But I think that that is what is worrying him. Quote: I am still in the process of working my way through C++ and I don't have a copy of the official standard, so I was hoping a more learned individual would be able to elucidate this troublesome issue for me. "Pracitcal C++ Programming" recommends against the use of increment and decrement operators within statements, but I've learned to really enjoy them. A quick rule of thumb: There's no problem in using increment and decrement operators within statements, provided that the variable being incremented or decremented appears nowhere else in that statement. I'd replace "appears nowhere else" with "is not used anywhere else". Aliasing is all too frequent in C++. I'd also say that trying to do too many things in one statement leads to obscure code, even when you don't hit undefined behavior. My own rule is to only use embedded ++ or -- when they can be viewed as conceptual IO, but this may be due to my Pascal background -- I also make heavy use of istream::peek. And of course, defining what is meant by "conceptual IO" probably asks more questions than it answers. All I can say is that I know what I mean. Quote: This rule does not cover all cases, but hits enough of the common ones to be useful. I fear that aliasing means that it misses a few cases that aren't really rare. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Potter Guest Posted: Sat Dec 13, 2003 2:19 am    Post subject: Re: ambiguity of post-increment and post-decrement On 12 Dec 2003 11:26:58 -0500, Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> wrote: Quote: In article <1071153311.127514 (AT) master (DOT) nyc.kbcfp.com>, Hyman Rosen [email]hyrosen (AT) mail (DOT) com[/email]> writes OP, this question is as old as the hills. The same undefined behavior exists in C, so it's been around for some 25 years. But it isn't undefined behaviour, it is unspecified behaviour which is not the same thing at all. Read 5/4 again. The order is unspecified; however, the statement in question reads the old value for a purpose other than to determine the new value which gives undefined behavior. Interesting that the phrase "unspecified behavior" occurs once in the standard. It is defined but never used. The phrase "behavior is unspecified" is used twice in 5/4 examples. Both uses wrongly label behavior which is undefined. Lots of things are unspecified; however, there seems to be no interest in unspecified behavior. John [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ron Natalie Guest Posted: Sat Dec 13, 2003 11:15 am    Post subject: Re: ambiguity of post-increment and post-decrement "Severin Ecker" <secker (AT) gmx (DOT) at> wrote Quote: could you please give a quick example of where the rule doesn't hold? perhaps when using in different branches of the ?: operator? foo = x ? i++ : a[i]; i can't think of any other example.. Sure, just about anything else that has a sequence point between the two uses of i is fine: foo = i++, a[i]; foo = i++ && a[i]; etc... [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Chris Mantoulidis Guest Posted: Sun Dec 14, 2003 8:47 pm    Post subject: Re: ambiguity of post-increment and post-decrement I've done some tests for the issue with my GNU G++ compiler... i++ is executed at the END of the WHOLE STATEMENT... ++i is executed as it's seen and the executions of ++x and --x are executed from left to right part of "=". I haven't done any research about the order they are executed at the right part of the "=". For example... int a[] = {0,0,0,0,0} int i = 1; (the above will be used in all examples) example1: a[i] = i++; result: a={0,1,0,0,0} and i = 2. So i was increased after the whole thing was executed -- example2: a[i] = ++i; result: a={0,2,0,0,0} and i = 2. So i was increased after its value was taken one time for indexing; it was increased when the ++ operator was found. -- example3: a[i++] = i++; result: a={0,1,0,0,0} and i = 3. So both ++'s where executed at the end. Like ex1. -- example4: a[++i] = ++i; result: a={0,0,3,0,0} and i = 3. Both where executed when read... Like ex2 -- example5: a[i++] = ++i; result: a={0,2,0,0,0} and i = 3. The first ++ was executed when read (see ex2,4) and the 2nd ++ was executed at the end (see ex1,3) -- example6: a[++i] = i++; result: a={0,0,2,0,0} and i = 3. [1st ++ -> see ex2,4] [2nd ++ -> see ex1,3] ----- cmad... [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.