From -802399501028867890 X-Google-Thread: f78e5,670b6cf407a24b27 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Fri, 05 Aug 2005 18:20:07 -0500 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: Alberto Barbati User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en, it MIME-Version: 1.0 Newsgroups: comp.std.c++ Subject: Re: return value dtor accessibility References: Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Message-ID: X-Complaints-To: abuse@net24.it Organization: [Infostrada] X-Virus-Scanned: by amavisd-new at libero.it serv7 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: Fri, 5 Aug 2005 18:18:27 CST Lines: 99 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-pJ7ikSSQcoolTgmJJw39DAILCO4FgrCwcdBBf/yZse20N/j9MnZPDNs4CCWL6tYNyoEv6s40707bZOC!cegX1rC9KAF+WGaXwLMQK8pYsOgpXoN+3TWxtPwGGJP8iq8TrcaGq/znHblbrj9xob9LUhERPOTV!lOQKB37uOniYQfVEy+8kfyVKEw== 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++:1681 Pavel Kuznetsov wrote: > Should the examples below compile according to the > standard? And what is exact wording which leads to > the answer you propose? > > > > My intuitive answer was 'no' for all three cases, because > at the point of the call of f() destructor of its return > value is either can't be implicitly defined, > or inaccessible. I agree with this interpretation. > But when I tried to compile these examples with four > different compilers, all of them gave different results: > > (1) (2) (3) > CodeWarrior 9.5 > for Mac OS X failed succeeded succeeded > MinGW GCC 3.4.2 failed failed failed > VC++7.1 succeeded failed failed > Comeau 4.3.3 for Windows succeeded succeeded failed MinGW looks the only compliant compiler here =:-| > My understanding is that this difference can be explained > by subtle differences of RVO implementations. OTOH I always > thought that RVO should not influence dtor accessibility > checks in such cases... 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. 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. > I was not able to find exact wording (or combination of) > which would specify that destructor accessibility is > verified for return values of function calls at the point > of function call. > > Is it my insufficient diligence or is it in fact > unspecified? It seems to me that everything you need is in 12.2/1 and 12.2/3: 12.2/1: Temporaries of class type are created in various contexts: [...], returning an rvalue (6.6.3), [...] 12.2/3: "[...] Similarly, the destructor shall be called for a temporary with a non-trivial destructor (12.4). [...]" Of course, class A has a non-trivial destructor in all three cases: 12.4/3: "[...] A destructor is trivial if it is an implicitly-declared destructor and if: � all of the direct base classes of its class have trivial destructors and � for all of the non-static data members of its class that are of class type (or array thereof), each such class has a trivial destructor." In case (2) and (3) the destructor is not trivial because it is not implicitly declared. Moreover, the destructor is inaccessible and so the code is ill-formed by 11/4. In case (1) there is a non-static data member that does not have a trivial destructor (N::~N is not implicitly declared) and in that case the code is ill-formed because of 12.4/5: 12.4/5: "An implicitly-declared destructor is implicitly defined when it is used to destroy an object of its class type (3.7). A program is ill-formed if the class for which a destructor is implicitly defined has: � a non-static data member of class type (or array thereof) with an inaccessible destructor, or � a base class with an inaccessible destructor" 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. However I can't see how the compiler could avoid destroying the temporary in the caller context (sematically speaking, i.e.: regardless of optimizations). HTH, Alberto --- [ 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 ]