From -4374616765691298147 X-Google-Thread: f78e5,670b6cf407a24b27 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeed.stueberl.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: pavel@despammed.com ("Pavel Kuznetsov") Newsgroups: comp.std.c++ Subject: Re: return value dtor accessibility Date: Sun, 7 Aug 2005 01:26:56 GMT Lines: 75 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Trace: news.demon.co.uk 1123378022 5886 158.152.254.254 (7 Aug 2005 01:27:02 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 7 Aug 2005 01:27:02 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Opera M2(BETA1)/8.02 (Win32, build 7668) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j771QuMK002207; Sun, 7 Aug 2005 11:26:56 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1692 Alberto, thanks for your answer! > MinGW looks the only compliant compiler here =:-| I tried one of the fresh builds of VC++ 8, and it seems to reject all of the three examples too. > 12.2/1: "[...] Even when the creation of the temporary object is avoided > (12.8), all the semantic restrictions must be respected as if the > temporary object was created. [Example: even if the copy constructor > is not called, all the semantic restrictions, such as accessibility > (clause 11), shall be satisfied. ]" > > In other words, differences of RVO implementation should not affect the > well-formedness of the code or lack thereof. Yes, this is exactly the place of the standard I was thinking about, but I am not sure whether we can rely on it, because as you are saying later, it is not explicitly said, or to be more precise we were not able to find corresponding wording, that the temporary returned is destroyed in the context of the caller, and that dtor accessibility checks are done in the context of the caller. > BTW, I don't think that RVO is even involved in any of those examples, > as it is an optimization that may affect the callee, but not to the > caller. Yes I thought the same, but the only thing which comes to my mind and behaves that irregular and depends on the presence of user-defined copy constructors, destructors etc. is RVO. But of course that was my wild guess. > It seems to me that everything you need is in 12.2/1 and 12.2/3: I thought so until I noticed that 12.2/1 is talking about *returning* a value, and not about *calling* a function, and I was not able to find any particular place in the standard which would define where accessibility of a destructor is checked for the value returned. > 12.2/1: Temporaries of class type are created in various contexts: > [...], returning an rvalue (6.6.3), [...] > The only doubt I have with this argumentation is that 12.2/1 explicitly > refers to 6.6.3 which is about the return statement, that is something > which pertains to the callee context that returns the temporary but not > to the caller context that receives the temporary, as in your examples. Yes, that is exactly what confuses me. > However I can't see how the compiler could avoid destroying the > temporary in the caller context (sematically speaking, i.e.: regardless > of optimizations). Well that is why I think that all of my examples are ill-formed, but I wanted to see an explicit provision in the standard, because common sense is not enough when the major compilers disagree. Anyway, thanks again for your interpretation. I hope that somebody would be able to find some definitive place in the standard which we could missed though... Otherwise I think it would warrant a DR, wouldn't it? -- Pavel --- [ 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 ]