public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c++/7522: access by friend function's default argument
Date: Thu, 31 Oct 2002 08:46:00 -0000	[thread overview]
Message-ID: <20021031164602.31144.qmail@sources.redhat.com> (raw)

The following reply was made to PR c++/7522; it has been noted by GNATS.

From: Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7522: access by friend function's default argument
Date: Thu, 31 Oct 2002 17:43:00 +0100

 On Wed, Oct 30, 2002 at 11:32:04PM -0000, bangerth@dealii.org wrote:
 > Synopsis: access by friend function's default argument
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Wed Oct 30 15:32:03 2002
 > State-Changed-Why:
 >     I don't think this is a bug. 11.0.7 states:
 >     7 The  names  in  a  default argument expression (_dcl.fct.default_) are
 >       bound at the point of declaration, and access is checked at that point
 >       rather than at any points of use of the default argument expression.
 >     
 >     I don't see anything right away in the standard that for
 >     checking access to the names used in the default value has
 >     to happen inside the scope of the function that uses them,
 >     but common reasoning would suggest that the enclosing scope
 >     is used, in which case the befriended function is not
 >     taken into account.
 >     
 >     I'll put this report into feedback mode. Please let us know
 >     if you can follow my reasoning, or whether we shall reopen
 >     the report.
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7522
 
 I admit I am not totally sure about this. Prior to submitting the PR,
 I asked for clarification in comp.lang.c++.moderated and
 comp.std.c++, but whithout success.
 
 The reference to 11.0.7 does not totally convince me; as I read it,
 the default argument expression has to undergo the same access checks
 as any other name bound in the parameter list of the function
 declaration. When I prepared an example I found g++ 3.2 seems to apply
 the rules inconsistently. Please consider:
 
  class A {
  private:
      class AInner {
      public:
          AInner(int i);
      };
 
      static const AInner ai;
      friend void f1(const A::AInner& x);
      friend void f2(const A::AInner& x);
      friend void f3(const A::AInner& x);
  };
 
  const A::AInner A::ai(5);
 
  void f1(const A::AInner& x);                  // ok
  void f2(const A::AInner& x = A::AInner(5));   // ok
  void f3(const A::AInner& x = A::ai);          // error
 
 
 If I follow your reasoning, then all three function declarations
 should be flagged as erroneous, I think. But g++ 3.2 complains about
 the last declaration only. 
 
 Even if I conceded that only the default argument expressions in this
 example should be checked at namespace scope for access violations:
 Why should the constructor of the private member class A::AInner be
 accessible, but not the private static member variable A::ai?
 
 For what it is worth, Comeau 4.3 accepts the above code.
 
 Regards
 
 Christoph
 
 -- 
 http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
 LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/
 


             reply	other threads:[~2002-10-31 16:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31  8:46 Christoph Ludwig [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-28 16:58 bangerth
2003-01-17  8:46 Christoph Ludwig
2002-10-31  9:24 bangerth
2002-10-30 15:32 bangerth
2002-08-07  8:46 Christoph Ludwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021031164602.31144.qmail@sources.redhat.com \
    --to=cludwig@cdc.informatik.tu-darmstadt.de \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).