From 8276537102791797272 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,8ba01a147f26fb88 X-Google-Attributes: gidf78e5,public From: James.Kanze@dresdner-bank.com Subject: Re: ++var and throw Date: 1999/09/24 Message-ID: <7sdi5k$b86$1@nnrp1.deja.com>#1/1 X-Deja-AN: 528963517 Approved: Fergus Henderson References: <7sb2gi$qbg3@interserv.etn.com> X-Original-Date: Thu, 23 Sep 1999 15:49:14 GMT X-Http-User-Agent: Mozilla/4.06 [de] (WinNT; I) X-Complaints-To: news@news.unimelb.edu.au X-Http-Proxy: 1.0 x30.deja.com:80 (Squid/1.1.22) for client 193.194.7.84 X-Trace: ariel.ucs.unimelb.edu.au 938158652 24398 128.250.37.153 (24 Sep 1999 07:37:32 GMT) Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Sep 23 15:49:14 1999 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN+sqLuEDnX0m9pzZAQFnvgGAirp2nRcuECBpjKSgwrnMLeKq2hnjF5eL a2VbAoUVcZnuAeLpWyDWFjm8B6LODicb =mfZu X-MyDeja-Info: XMYDJUIDkanze NNTP-Posting-Date: 24 Sep 1999 07:37:32 GMT Newsgroups: comp.std.c++ In article , Francis Glassborow wrote: > > In article <7sb2gi$qbg3@interserv.etn.com>, Ed Brey > writes > >In the spirit of the ++var thread, I have a spin-off question (I > >coincidentally just ran into this while doing real work). Consider the > >statement: > >*p++ = f(); > >If f() throws, is p guaranteed to not be incremented? Where does the > >IS define this or say that it is undefined? > I do not think there are any guarantees. f() can be evaluated before > or after *p, the side-effect caused by ++ (writing back to p) can > happen anytime before completion of the whole expression. I hope that > does not mean that it can be interrupted by the throw of an exception > because that could leave p in an unstable state. This is an interesting question. You don't need exceptions to see the problem; all it takes is for p to be global and accessible by f. It isn't hard to imagine a machine on which updating a pointer required two writes. If the compiler is allowed to insert the call to f between the two writes, and f accesses p, then you could get undefined behavior. (If the update is required to be atomic, f might see the value before incrementation, or after, but in both cases, it could at least legally look at the pointer.) I'm unable to find any exact words to cover this, but I'm pretty sure that the intend is that this should work (both in C and C++). Note too that the call to f introduces a sequence point. According to the standard, at a sequence point, all volatile values are reputed stable. As I understand it, however, in the abstract machine described by the standard, there is no real difference between volatile variables and non volatile variables -- the volatile-ness simply indicates whether the behavior is observable or not. Of course, if the above counts on the sequence point of the function call to be defined, we have a problem with: *p ++ = (throw 1 , 0) ; (The comma operator introduces a sequence point, but it is irrelevant, because the code throws before, and throw is not a sequence point.) -- James Kanze mailto: James.Kanze@dresdner-bank.com Conseils en informatique orient�e objet/ Beratung in objekt orientierter Datenverarbeitung Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627 Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. --- [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]