RE: Nested Class Member Access

RE: Nested Class Member Access

[Steven L. Zook]

Is this behavior on GCC's part (that is, nested classes are members of the enclosing class and thus have all access rights that other members have) intentional? 

If so, should it be documented in the "Extensions to the C++ Language" section of the GCC online documents.

In any case, it seems that I should not submit a problem report.

-----Original Message-----
From: Florian Weimer [mailto:fw@deneb.enyo.de]
Sent: Thursday, September 02, 2004 12:23 PM
To: Steven L. Zook
Cc: GCC Mailing List (E-mail)
Subject: Re: Nested Class Member Access


* Steven L. Zook:

> According to ISO/IEC 14882-2003 (is this the correct standard for
> GCC?) 11.8.1 [class.access.nest], I believe this should be an
> error. The paragraph says that nested classes have no special access
> rights to enclosing class members. Since cOuter::Variable is
> private, cOuter::cInner::Function should not have access to it.

Your are correct that your example is not valid C++, but this may
change:

  <http://ra.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#45>

Re: Nested Class Member Access

[Giovanni Bajo]

Steven L. Zook wrote:

> Is this behavior on GCC's part (that is, nested classes are members of the
> enclosing class and thus have all access rights that other members have)
> intentional?

Yes.

> If so, should it be documented in the "Extensions to the C++ Language"
> section of the GCC online documents.

Not really, because it is actually part of C++0x, so it is not a real
extension in the traditional term. Instead, I would like to define a new
language dialect (-std=c++0x) to activate such behavours (that is,
implementation of DRs which are in WP status). There have been some talk
about it, but no patches yet.

Giovanni Bajo

Re: Nested Class Member Access

[Joe Buck]

On Fri, Sep 03, 2004 at 08:26:26PM +0200, Giovanni Bajo wrote:
> Steven L. Zook wrote:
> 
> > Is this behavior on GCC's part (that is, nested classes are members of the
> > enclosing class and thus have all access rights that other members have)
> > intentional?
> 
> Yes.
> 
> > If so, should it be documented in the "Extensions to the C++ Language"
> > section of the GCC online documents.
> 
> Not really, because it is actually part of C++0x, so it is not a real
> extension in the traditional term. Instead, I would like to define a new
> language dialect (-std=c++0x) to activate such behavours (that is,
> implementation of DRs which are in WP status). There have been some talk
> about it, but no patches yet.

Speaking of c++0x, I'd dearly like to see an implementation of the "auto"
proposal that Stroustrup has championed, so loops iterating over
containers can be written simply and uniformly as

    for (auto iter = container.begin(); iter != container.end(); ++iter) {
	...;
    }    

Re: Nested Class Member Access

[Florian Weimer]

* Steven L. Zook:

> According to ISO/IEC 14882-2003 (is this the correct standard for
> GCC?) 11.8.1 [class.access.nest], I believe this should be an
> error. The paragraph says that nested classes have no special access
> rights to enclosing class members. Since cOuter::Variable is
> private, cOuter::cInner::Function should not have access to it.

Your are correct that your example is not valid C++, but this may
change:

  <http://ra.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#45>

Nested Class Member Access

[Steven L. Zook]

I'm using gcc 3.4.1 (I've also tried it with 3.3.1) m68k-elf and the following test file:



class cOuter { private: int Variable;
               public:  class cInner { public: int Function( cOuter * pOuter ); };
             };
int cOuter::cInner::Function( cOuter * pOuter ) { return pOuter->Variable; }



This fragment compiles without complaint, the produced code looks good. 

According to ISO/IEC 14882-2003 (is this the correct standard for GCC?) 11.8.1 [class.access.nest], I believe this should be an error. The paragraph says that nested classes have no special access rights to enclosing class members. Since cOuter::Variable is private, cOuter::cInner::Function should not have access to it.

I've searched bugzilla and found a couple of bugs posted against java for similar cases as well as #13495 (which may be related but whose example is rather obfuscated by templates).

Any C++ language lawyer comment would be appreciated. I will post a bug report if any GCC legal staff ;-) agrees that this is in violation.