From -8014156940547357026
X-Google-Thread: f78e5,670b6cf407a24b27,start
X-Google-Attributes: gidf78e5,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news1.google.com!news2.google.com!newsread.com!news-xfer.newsread.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!newsfeed2.telusplanet.net!newsfeed.telus.net!cyclone.bc.net!news.alt.net!comp-std-cpp-robomod!not-for-mail
From: "Pavel Kuznetsov" <pavel@despammed.com>
Newsgroups: comp.std.c++
Subject: return value dtor accessibility
Date: 5 Aug 2005 18:00:38 GMT
Organization: "Altopia Corp. - Usenet Access - www.altopia.com"
Lines: 87
Approved: Fergus Henderson <fjh@cs.mu.oz.au>, moderator of comp.std.c++
Message-ID: <op.su0k5nqzrcu39t@ibm-t42.domain.actdsltmp>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; delsp=yes; charset=windows-1251
Content-Transfer-Encoding: 8bit
Return-Path: <devnull@stump.algebra.com>
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
User-Agent: Opera M2(BETA1)/8.02 (Win32, build 7668)
X-Virus-Scanned: amavisd-new at ucar.edu
X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU
X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU
Xref: g2news1.google.com comp.std.c++:1672

Should the examples below compile according to the
standard? And what is exact wording which leads to
the answer you propose?

(1)

   struct A {
     struct N {
     private:
       ~N();
     };
     N n_;
   };

   A f();

   int main()
   {
     f();
   }

(2)

   struct A {
   private:
     ~A();
   };

   A f();

   int main()
   {
     f();
   }

(3)

   struct A {
   private:
     A(A const&);
     ~A();
   };

   A f();

   int main()
   {
     f();
   }

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.

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

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...

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?

-- 
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                       ]