From -7832218655797113430 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: Wed, 23 Nov 2005 00:00:14 -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: "Greg Herlihy" Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Organization: http://groups.google.com Message-ID: <1132722639.345095.296070@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 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/416.11 (KHTML, like Gecko) Safari/416.12,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=70.231.136.230; posting-account=JdllFQ0AAAC-QghphnHMZz5q0GHnzGUJ 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 23:53:09 CST Lines: 77 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-nPFD0+bbPZsZpAdpznZcRtKtdckW3/if9vY9E0j08YLXOaqINUmPAqlfCXykIRL5v3Je90IVZDwQ3D/!twYQNa5zz3zRNe85vLhM6/vfLCd7HYbSx5IDMpBAnnf2V3RwSkkX8KifEVLvwlbpYB7CC14INox/!4n6brKMayUgx3sUoM4SkjAniASG1/0iA7Dw4X8sMRZ8= 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++:2579 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? Your analysis is correct. With an overloaded operator[], the evaluation of the expression i=v[i++] is no longer unspecified, but is, in fact, defined. > 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'). Absolutely. There is no requirement that an overloaded operator behave at all like the built-in operator. For example, a program could overload the assignment operator (=) to test for equality, and overload the equality operator (==) to perform an assignment, for any user-declared type. It would be perfectly legal for a program to do so, though probably not a particularly good idea. At least not if one values consistency. But rather than have the Standard restrict overloaded operators in some arbitrary manner, it simply leaves their implementation up to the programmer's own good judgement. > 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? 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? It depends on the context in which i++ appears. As a function parameter, i++ must be evaluated before the function call is made. Since the function must be passed the value of i before it is incremented, the compiler must first copy i, increment it, and then pass the copy of i to the function being called. > [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. 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." I believe the Standard has some examples to illustrate when result of evaluating an expression is unspecified and when it is undefined. Essentally, the result of evaluating i = v[i++] is unspecified because i's value is accessed only once. The evaluation of i++ = v[i++] would be undefined, since i's value is accessed more than once between sequence points. Greg --- [ 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 ]