From -5783925554099269632 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 22 Nov 2005 09:10:17 -0600 Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Delivered-To: std-c++@ucar.edu From: kuyper@wizard.net Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Organization: http://groups.google.com Message-ID: <1132662585.882464.24110@f14g2000cwb.googlegroups.com> References: <1132629737.664847.151630@o13g2000cwo.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=66.234.255.45; posting-account=bPBxkgwAAABzUwlEAMy-xGlLqZFJ5Jz_ X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Tue, 22 Nov 2005 09:02:42 CST Lines: 101 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-YayDw4KApJhHOvHZ6c/Vd+oHLi8USOsb3OzyekUCsERmYEB7xjmpLRdRwyR6dQS3oG29TYc/O0/7RtL!cOISXUxL2QAJpQCMYRfufISre3euz8ytHzpXzaeao0ZKvKO6YSoxPuRShNH+y1GT/5EZTCX+wE7s!yGsTSqruU5R+DVv2N5/JcqnGbYp9eMGK7af6LaSs4g== X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:2575 pongba@gmail.com wrote: > C++03 5/4: > [Example: > i = v[i++]; // the behavior is unspecified > . > ] > > I wanna ask that if v is a std::vector which overloads operator[], is > this unspecified any more? > > What I understand is that there's a sequence point at the entry and > exit of a function call, well, operator function certainly is a > function, so if we change that 'v' to a object of std::vector, v[i++] > becomes a function call, the side effect of which takes place before > the assignment operation, therefore 'i' gets a determinable value, > which is v[*old value of the i*], which of course is not unspecified. > > That said, I wonder if this analysis is right, did I miss or > misunderstand anything? Yes, that's correct. When operators are overloaded, it's actually just shorthand for function calls, with all of the corresponding sequence points. > If that is true, is this an evidence that some inconsistency, in some > extremely non-obvious way, exists between build-in operator and > operator function(informally known as 'overloaded operator'). Yes, this is one of the several inconsistencies between them. Backwards compatibility with C was an important objective during the development of C++, which prevented complete consistency between built-in and user-defined operators. Note: the phrase "overloaded operator" refers to the operator that is being overloaded. The standard uses the term "overloaded operator function" for the function that overloads the overloaded operator, so there's nothing particularly informal about that terminology. > Another question is: > > What is the side-effect of 'i++' actually? Two options, first of which > is "fetch i from memory, add it by 1, write the new value back", second > is "write the new value stored previously somewhere into the storage of > 'i'". Is the answer 'both' or 'either' or whatever? Accessing the value of 'i' is not a side effect unless 'i' was declared volatile. Otherwise, the only side effect of i++ is the writing of the new value. The read of the previous value (if not volatile), and the calculation of the new value, are the "main" effect. See 1.9p7 for the exact definition of "side effect". > Plus, the words > below(also excerpted from [c++03;5/4])are really puzzling to me, can > anyone explain it please? Does it have anything to do with the two > questions I asked? > > [C++03;5/4]"Between the previous and next sequence point a scalar > object shall have its stored value modified at most once by the > evaluation of an expression. This part is pretty straightforward. Several different operators can modifiy the value of an object: all of the assignment operators, ++ and --. If two such operators modify the value of the same object without an intervening sequence point, it's a violation of 5p4. As a practical matter, this is because the absence of a sequence point allows the implementor to rearrange the generated machine code, so that there's no telling which of the two modifications will occur first, and it may even be that the two modifications interfere with each other to produce a result that's different from what would have happened if either modification had been the only one. > Furthermore, the prior value shall be > accessed only to determine the value to be stored.The requirements of > this paragraph shall be met for each allowable ordering of the > subexpressions of a full expression; otherwise the behavior is > undefined." This one is much more difficult. If you read the current value of an object, and then write to that same object, without an intervening sequence point, then you can't read the value for any purpose other than determining the value that is to be written. Again, as a practical matter that's because the absences of a sequence point allows the read and the write to be in any order, and it even allows them to interfere with each other. It's allowed only if it's inherently impossible to know what value to write, until you've finished reading the value; that guarantees that the read and the write have to be in the right order, and can't interfere with each other, even in the absence of a sequence point. However, there's a lot of confusion and argument about what constitutes a use of the value for that purpose. The safest thing to do is to avoid any construct that might be construed as using the previous value for any other purpose. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]