C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  preincrement and postincrement operators Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message dragoncoder Guest Posted: Sat Jul 16, 2005 10:26 am    Post subject: preincrement and postincrement operators Hello all, While working some code out, I found that result of a preincrement operator is an lvalue whether that of a postincrement operator is an rvalue. That means we can write. ++x = y; but cannot write x++ = y; I was wondering what could be the rationale behind putting such an assymetry in the language. Can someoe help me out ? /P [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top albrecht.fritzsche Guest Posted: Sat Jul 16, 2005 11:39 pm    Post subject: Re: preincrement and postincrement operators dragoncoder wrote: Quote: While working some code out, I found that result of a preincrement operator is an lvalue whether that of a postincrement operator is an rvalue. That means we can write. ++x = y; but cannot write x++ = y; I was wondering what could be the rationale behind putting such an assymetry in the language. Can someoe help me out ? Try to implement those then you will see why - while the preincrement returns a reference to the changed x is the postincrement returning a copy of the original x. Ali [ 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: Sat Jul 16, 2005 11:43 pm    Post subject: Re: preincrement and postincrement operators "dragoncoder" <pktiwary (AT) gmail (DOT) com> wrote Quote: While working some code out, I found that result of a preincrement operator is an lvalue whether that of a postincrement operator is an rvalue. That means we can write. ++x = y; but cannot write x++ = y; I was wondering what could be the rationale behind putting such an assymetry in the language. Can someoe help me out ? The example that originally motivated the rule was something like this: class Foo { public: // ... Foo& clear() { return *this = Foo(); } // ... }; The person who wrote this had trouble understanding why his program crashed. The reason was that at the time, operator= returned an rvalue by default, and we had not yet adopted the rule that you can't bind a nonconst reference to an rvalue. So the function returned a reference to a temporary that was then destroyed. The author of this program was even more distressed to find that rewriting the return statement as *this = Foo(); return *this; would make the program work just fine, because *this was now an lvalue and the function would return a reference to it. In C, of course, if x is the same type as the function returns, then return x = y; always has the same effect as x = y; return x; so it was just a little distressing that C++ did not maintain this equivalence. After careful study, we concluded that the equivalence could be restored without breaking compatibility if we changed one rule slightly: Whenever a built-in operator returns one of its operands as its result, the result should be an lvalue whenever the operand is an lvalue. This rule includes not only the left operand of =, but also the right operand of ,, the left operand of each of the compound assignment operators, and the operand of prefix ++ and --. It does not, however, include the operand of postfix ++ or -- because each of those operators returns a copy of the operand, not the operand itself. [ 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: Sat Jul 16, 2005 11:47 pm    Post subject: Re: preincrement and postincrement operators In article <1121500431.794489.189640 (AT) z14g2000cwz (DOT) googlegroups.com>, dragoncoder <pktiwary (AT) gmail (DOT) com> writes Quote: Hello all, While working some code out, I found that result of a preincrement operator is an lvalue whether that of a postincrement operator is an rvalue. That means we can write. ++x = y; You can write it and the compiler may even compile it but the consequence of executing the resulting program is undefined behaviour. (You modify the same object twice between sequence points) Quote: but cannot write x++ = y; I was wondering what could be the rationale behind putting such an assymetry in the language. Can someoe help me out ? It is actually a case of allowing as much freedom as is possible. When you pre-increment a variable the original object can be used and in some circumstances it is useful to do so (though not in the case you use.) In the case of post increment, the object still needs updating not later than the next sequence point yet we want the prior value. The following isn't good quality code but it should show the difference: int foo(int &); int main(){ int j(0); foo(++j); // no implementation problem, bind the parameter of foo to j, but increment it before you do so. foo(j++); // big problem, you need to bind the argument of foo to j but it seems that this should be before j is incremented, yet j must be incremented before entry to foo because there is a sequence point after the evaluation of the arguments. }; Note that the difficulty goes away for int bar(int const &) because a temporary can now be used for the value of j before incrementing. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top szymon.rozga@gmail.com Guest Posted: Sat Jul 16, 2005 11:49 pm    Post subject: Re: preincrement and postincrement operators I would like to see the proper answer to this one, but off the top of my head it seem intuitive in that, ++x will add 1 to x and return x x++ will add 1 to x and return x-1 then ++x = y, will be equivalent to x= x+1 x=y whereas, x++ = y, would be equivalent to x = x +1 x-1 = y -Szymon [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Sat Jul 16, 2005 11:58 pm    Post subject: Re: preincrement and postincrement operators dragoncoder wrote: Quote: While working some code out, I found that result of a preincrement operator is an lvalue whether that of a postincrement operator is an rvalue. That means we can write. ++x = y; but cannot write x++ = y; I was wondering what could be the rationale behind putting such an assymetry in the language. Can someoe help me out ? I think that the rationale is basically that if an operator refers to an object, and the value of that object is the result, the operator returns an lvalue. Note that this is *not* the case in C -- neither prefix nor postfix ++ result in lvalues in C. Note too that you *cannot* write: "++ x = y". It is just as illegal in C++ as in C, albeit for different reasons. The difference is that in C++, it is undefined behavior, whereas in C, it requires a compiler diagnostic. -- James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34 [ 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: Tue Jul 19, 2005 9:15 am    Post subject: Re: preincrement and postincrement operators Francis Glassborow wrote: Quote: dragoncoder <pktiwary (AT) gmail (DOT) com> writes That means we can write. ++x = y; You can write it and the compiler may even compile it but the consequence of executing the resulting program is undefined behaviour. (You modify the same object twice between sequence points) Once more, I point out that after decades of use, people still have no clue that these kinds of issues even exist. There is no excuse, none at all, for still having ambiguous order of evaluation. [ 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: Tue Jul 19, 2005 11:32 am    Post subject: Re: preincrement and postincrement operators In article <200507181506.j6IF6euC095210 (AT) horus (DOT) isnic.is>, Hyman Rosen <hyrosen (AT) mail (DOT) com> writes Quote: Francis Glassborow wrote: dragoncoder <pktiwary (AT) gmail (DOT) com> writes That means we can write. ++x = y; You can write it and the compiler may even compile it but the consequence of executing the resulting program is undefined behaviour. (You modify the same object twice between sequence points) Once more, I point out that after decades of use, people still have no clue that these kinds of issues even exist. There is no excuse, none at all, for still having ambiguous order of evaluation. Order of evaluation has very little to do with it, it is the order of execution of side-effects between sequence points that is the major issue. As long as the C++ (and C) rule with regards to not modifying an object more than once and, if an object is to be modified, not reading it for reasons that are not related to its modification, side-effects are transparent. Functional programming treats mutation as deeply suspect and something that should be avoided if at all possible. C and C++ allow mutation but places a perfectly reasonable limitation on it (not more than once between sequence points, and if you read the value from an object that you are going to write to that read must, at least in part, be for the purpose of determining what to write. Consider i = ++j + j; Note that order of evaluation is useless for preventing problems unless you also insist that write updates must happen immediately and all other evaluations be suspended until that has happened. Of course it is shocking that so many programmers have no idea that their code is problematic, but it is even more shocking that publishers continue to publish books written by ignorant authors that are then used by teachers who, whatever their teaching ability, are themselves ignorant of so many of the basics of the programming language they purport to teach. If someone giving an introductory course on electric wiring confused live and neutral wires they would quickly either learn better or find another less demanding job. The same would apply to introductory texts for novice electricians. Why do we not apply the same standards to programming? -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ 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: Tue Jul 19, 2005 7:12 pm    Post subject: Re: preincrement and postincrement operators Francis Glassborow wrote: Quote: Order of evaluation has very little to do with it, it is the order of execution of side-effects between sequence points that is the major issue. When I speak about order of evaluation I mean to include deterministic execution of side effects. Sorry if that wasn't clear. Quote: Note that order of evaluation is useless for preventing problems unless you also insist that write updates must happen immediately and all other evaluations be suspended until that has happened. Yes, that's exactly what I do insist upon. Quote: Of course it is shocking that so many programmers have no idea that their code is problematic No, what is shocking is that a misfeature that is no longer of any benefit, and which is endlessly confusing even to experts, evidenced by any number of posts to these newsgroups, is allowed to remain in the language. You will note, by the way, that if x is of a class type which defines an appropriate operator++() then '++x = y;' is well-defined. The OP didn't say anything about the type of x, so in fact your claim that his code exhibits undefined behavior is unfounded. This illustrates once again the swamp that is sequence points, and demonstrates my point about how even experts go astray. [ 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: Wed Jul 20, 2005 2:14 pm    Post subject: Re: preincrement and postincrement operators Francis Glassborow wrote: Quote: If someone giving an introductory course on electric wiring confused live and neutral wires they would quickly either learn better or find another less demanding job. The same would apply to introductory texts for novice electricians. Why do we not apply the same standards to programming? Because we have a choice. The fact that life and neutral wires are different is not an arbitrary choice, but is based on the laws of physics. The fact that if i is an int, (++i, ++i) is well defined, but f( ++i, ++i ) isn't, is more than arbitrary -- I'd call it abherant. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Keith H Duggar Guest Posted: Wed Jul 20, 2005 11:24 pm    Post subject: Re: preincrement and postincrement operators Quote: Francis Glassborow wrote: If someone giving an introductory course on electric wiring confused live and neutral wires they would quickly either learn better or find another less demanding job. The same would apply to introductory texts for novice electricians. Why do we not apply the same standards to programming? Because we have a choice. The fact that life and neutral wires are different is not an arbitrary choice, but is based on the laws of physics. The fact that if i is an int, (++i, ++i) is well defined, but f( ++i, ++i ) isn't, is more than arbitrary -- I'd call it abherant. LOL, good one :-) In addition to lack of physical laws, I believe it is also because much of the software industry has thus far been allowed by society to ignore poor coding standards and education. Much of Engineering has evolved such tight standards and solid education because when we Engineers make mistakes, people die. I'm reminded of my eccentric undergrad physics teacher who when a student complained that he didn't give partial credit on his tests responded: "Partial credit? ... Partial credit! Every time I get on an airplane I say 'Thank God that Engineer didn't get partial credit!'" And when people die, companies lose money, a lot of money. When the day comes that victims of shoddy consumer software start holding companies accountable I believe you still see some serious improvements. PS. An alternative may be shock therapy. [ 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: Thu Jul 21, 2005 3:53 pm    Post subject: Re: preincrement and postincrement operators Keith H Duggar wrote: Quote: Francis Glassborow wrote: If someone giving an introductory course on electric wiring confused live and neutral wires they would quickly either learn better or find another less demanding job. The same would apply to introductory texts for novice electricians. Why do we not apply the same standards to programming? Because we have a choice. The fact that life and neutral wires are different is not an arbitrary choice, but is based on the laws of physics. The fact that if i is an int, (++i, ++i) is well defined, but f( ++i, ++i ) isn't, is more than arbitrary -- I'd call it abherant. LOL, good one :-) In addition to lack of physical laws, I believe it is also because much of the software industry has thus far been allowed by society to ignore poor coding standards and education. Much of Engineering has evolved such tight standards and solid education because when we Engineers make mistakes, people die. I suspect that it depends on which engineering, and which software. People have already died because of programming errors. Quote: I'm reminded of my eccentric undergrad physics teacher who when a student complained that he didn't give partial credit on his tests responded: "Partial credit? ... Partial credit! Every time I get on an airplane I say 'Thank God that Engineer didn't get partial credit!'" And when people die, companies lose money, a lot of money. When the day comes that victims of shoddy consumer software start holding companies accountable I believe you still see some serious improvements. Certainly. But I think it's already happened in a lot of places. Looking back over the last 25 years, in well over half the projects I've worked on, there were conventional penalties for software failures; in at least one case (a locomotive brake system), I think we could have been held criminally liable. And from what I understand, at least one place has reached SEI level 5. Of course, there are other places... -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Keith H Duggar Guest Posted: Fri Jul 22, 2005 11:04 am    Post subject: Re: preincrement and postincrement operators [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: Keith H Duggar wrote: ... much of the software industry ... Much of Engineering has evolved such tight standards ... I suspect that it depends on which engineering, and which software. People have already died because of programming errors. Yes, of course you are right. There are common case studies I remember from school (Therac-25, etc). The key word in my comment was -much-. And specifically what I had in mind was Quote: ... shoddy consumer software ... where I thought consumer software would convey products such as word processors, spread sheets, photo editors, consumer os's, etc (ie Adobe, Microsoft, Apple, etc). Can you recall any cases yet where say Microsoft has been sued because Windows crashed and someone was harmed (or suffered substantial loss). Did they win? When that happens (more) then the proverbial excrement will hit the fan. Quote: Certainly. But I think it's already happened in a lot of places. Looking back over the last 25 years, in well over half the projects I've worked on, there were conventional penalties for software failures ... Point taken. Perhaps my comments aren't really relevant to particular language features then? Do you think increased liability for consumer software failure would lead to language improvements down the line? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Sun Jul 24, 2005 11:30 am    Post subject: Re: preincrement and postincrement operators Keith H Duggar wrote: Quote: kanze (AT) gabi-soft (DOT) fr wrote: Keith H Duggar wrote: ... much of the software industry ... Much of Engineering has evolved such tight standards ... I suspect that it depends on which engineering, and which software. People have already died because of programming errors. Yes, of course you are right. There are common case studies I remember from school (Therac-25, etc). The key word in my comment was -much-. And specifically what I had in mind was ... shoddy consumer software ... where I thought consumer software would convey products such as word processors, spread sheets, photo editors, consumer os's, etc (ie Adobe, Microsoft, Apple, etc). OK. I'll admit that I never even think of such things, as they are so far away from the type of work I usually do. Quote: Can you recall any cases yet where say Microsoft has been sued because Windows crashed and someone was harmed (or suffered substantial loss). Did they win? When that happens (more) then the proverbial excrement will hit the fan. It's an interesting question. I believe that the license says that they disclaim all responsibility, but I doubt that they can legally do that. (That's also an interesting question with regards to the GNU license. Can they really disclaim all responsibility because they don't charge for it.) On the other hand, I suspect that anyone trying to sue would have to prove that they'd used all of the normal precautions a professional would use: frequent backups, etc., but also, backup systems when a crash would have fatal, etc. I suspect, in fact, that naïve (or downright stupid) customers may be a large part of the problem. (Another part, of course, is that most companies don't seem to have realized that many of the same steps you take to improve quality also reduce development costs.) Quote: Certainly. But I think it's already happened in a lot of places. Looking back over the last 25 years, in well over half the projects I've worked on, there were conventional penalties for software failures ... Point taken. Perhaps my comments aren't really relevant to particular language features then? Do you think increased liability for consumer software failure would lead to language improvements down the line? I doubt it. C++ is also being used for some pretty critical systems, and that doesn't seem to have had much effect. The problem is that while the various undefined behaviors do increase the cost of developing software (even the cost of developing shoddy software), the increase isn't necessarily measurable, and nobody seems to care. Money is, apparently, much less of a motivating factor than one might think (and I'll admit that this surprises me). -- James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Keith H Duggar Guest Posted: Sun Jul 24, 2005 11:31 pm    Post subject: Re: preincrement and postincrement operators I realize now that this topic has probably strayed off topic for comp.lang.c++.m. Just wanted to point out that googling for - software liability - turns up some interesting links. [ 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.