In article <3B95030B.1F92D1C0@ebay.sun.com>, Mike Schilling
<mike.schilling@ebay.sun.com> writes
>> Now how, without breaking encapsulation, do you provide Y::Y1::Pimpl
>> with access to Y's private/protected parts? Indeed, as you are not
>> allowed to forward declare nested classes other than in the definition
>> of the enclosing class, this requires that Y::Y1 be defined within the
>> definition of Y.
>
>Well, by allowing:
>
>class Y {
>  class Y1; //forward declaration
>  friend class Y::Y1; // Should "friend class Y1" here mean the nested
>class or a top-level Y1?
>  ...
>};
>
>Which is a smaller change than automatically making nested classes
>friends.  Clearly this was considered and rejected -- why?

Well I can only speak for myself. The numerous defect reports concerning
'friend' and 'name look-up' issues strongly suggests to me that there is
a design concept error. Those of us who have been responsible for this
part of the standard are very tired of the fact that every change to the
wording has broken something else (another symptom of a broken design).

I actually can find no reason for the current position (must declare
friend inwards) other than the fact that in the early days classes were
only nested lexically and not semantically.



Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<czoiAJAxHQl7Ewd1@ntlworld.com>...
> >-- you can do it from
> >Y::Y1. Moreover: Y::Y1::Pimpl is an implementation detail of Y::Y1 and Y
> >don't have to know about it at all: what if I'll define Y::Y1::Pimpl_2,
> >Y::Y1::Pimpl_3, Y::Y1::Pimpl_4 next week?
>
> And that is exactly the point. If we no longer have to grant friendship
> inwards, it does not matter. Y does not need to know about helper
> classes in Y1 (to whatever nesting depth the implementor of Y1 finds
> convenient.
>

The word "inwards" gives me the impression that Y can access Y1's
private parts since Y1 is inside Y.  I know you mean the other way,
but do I have a language problem?

Granting Y1 to access anything in its enclosing class is very
natural/logical from the the point of view of scope rules.  I hope the
resolution will become the standard soon.

Xiao-Hui Wu

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
> >> That is an error that we are currently tackling. The current most likely
> >> solution is to allow nested classes access to the enclosing class
> >> private & protected members.
> >       Don't do it!!! This is the most awful solution!
 [snip]
> In a room of over 40 language experts exactly two wanted to retain the
> historical position.
 In other words you propose to implicitly generate the "friend
Outer::Inner;" statement every time I create Inner class? Very good, then
give me the ability to say "Inner is NOT a friend of Outer": I'm going to
use it most of my time.

> If you need to partition your data into mutually
> exclusive blocks then you can do so with two nested classes (with their
> data private. One can grant friendship to the enclosing class if that
> helps your design.
 And do the 40 language experts really think that it's much more easy to
define an additional inner class rather than not to say "friend
Outer::Inner;"?

> Martin O'Riordan has a detailed paper explaining why the historical rule
> breaks encapsulation (because friendship is not transitive, outer
> classes can find they need knowledge of inner classes implementation
> details where helper classes are being used inside the inner class.)
 Could you tell me pls. where I can take a look at this paper?
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B90B8FC.14C9BA55@iobox.com>, Sergey P. Derevyago <non-
existent@iobox.com> writes
>Francis Glassborow wrote:
>> >> That is an error that we are currently tackling. The current most likely
>> >> solution is to allow nested classes access to the enclosing class
>> >> private & protected members.
>> >       Don't do it!!! This is the most awful solution!
>       [snip]
>> In a room of over 40 language experts exactly two wanted to retain the
>> historical position.
>       In other words you propose to implicitly generate the "friend
>Outer::Inner;" statement every time I create Inner class? Very good, then
>give me the ability to say "Inner is NOT a friend of Outer": I'm going to
>use it most of my time.

You can already do this:

class X {
   class X1 {
   friend class X;
   ...
   };
   class X2 {
   ...
   };
};

class X2 has no access to the private parts of class X1 though X has.

And exactly why do you trust your self so little that you want to
protect your work from itself?

>
>> If you need to partition your data into mutually
>> exclusive blocks then you can do so with two nested classes (with their
>> data private. One can grant friendship to the enclosing class if that
>> helps your design.
>       And do the 40 language experts really think that it's much more easy to
>define an additional inner class rather than not to say "friend
>Outer::Inner;"?

Yes because of the problems of:

class Y {
  class Y1; //forward declaration
  ...
};

class Y::Y1 {
  struct Pimpl;
  ...
};

Now how, without breaking encapsulation, do you provide Y::Y1::Pimpl
with access to Y's private/protected parts? Indeed, as you are not
allowed to forward declare nested classes other than in the definition
of the enclosing class, this requires that Y::Y1 be defined within the
definition of Y.




Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
> >       In other words you propose to implicitly generate the "friend
> >Outer::Inner;" statement every time I create Inner class? Very good, then
> >give me the ability to say "Inner is NOT a friend of Outer": I'm going to
> >use it most of my time.
>
> You can already do this:
>
> class X {
>    class X1 {
>    friend class X;
>    ...
>    };
>    class X2 {
>    ...
>    };
> };
>
> class X2 has no access to the private parts of class X1 though X has.
>
> And exactly why do you trust your self so little that you want to
> protect your work from itself?
 Good question :) In C/C++ we don't have inner function for the almost same
reasons. I think you know them very well. However in the case of inner
classes you can use friend declaration if you "trust yourself" :)

> >> If you need to partition your data into mutually
> >> exclusive blocks then you can do so with two nested classes (with their
> >> data private. One can grant friendship to the enclosing class if that
> >> helps your design.
> >       And do the 40 language experts really think that it's much more easy to
> >define an additional inner class rather than not to say "friend
> >Outer::Inner;"?
>
> Yes because of the problems of:
>
> class Y {
>   class Y1; //forward declaration
>   ...
> };
>
> class Y::Y1 {
>   struct Pimpl;
>   ...
> };
>
> Now how, without breaking encapsulation, do you provide Y::Y1::Pimpl
> with access to Y's private/protected parts?
 Do you really think that Y::Y1::Pimpl must be the friend of Y? As for me,
I really doubt it. For example, Y::Y1 can be the friend of both Y and
Y::Y1::Pimpl for the almost the same results. In particular D&E shows us
that some features can not be accepted if they are intended to support a
poor style programming.

> Indeed, as you are not
> allowed to forward declare nested classes other than in the definition
> of the enclosing class, this requires that Y::Y1 be defined within the
> definition of Y.
 BTW is this a reasonable restriction? IMHO if class X knows that X::Y::Z
does exist it should be able to say "friend class X::Y::Z".
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>
> In article <3B90B8FC.14C9BA55@iobox.com>, Sergey P. Derevyago <non-
> existent@iobox.com> writes
> >Francis Glassborow wrote:
> >> >> That is an error that we are currently tackling. The current most likely
> >> >> solution is to allow nested classes access to the enclosing class
> >> >> private & protected members.
> >> >       Don't do it!!! This is the most awful solution!
> >       [snip]
> >> In a room of over 40 language experts exactly two wanted to retain the
> >> historical position.
> >       In other words you propose to implicitly generate the "friend
> >Outer::Inner;" statement every time I create Inner class? Very good, then
> >give me the ability to say "Inner is NOT a friend of Outer": I'm going to
> >use it most of my time.
>
> You can already do this:
>
> class X {
>    class X1 {
>    friend class X;
>    ...
>    };
>    class X2 {
>    ...
>    };
> };
>
> class X2 has no access to the private parts of class X1 though X has.

If such a change were made, X2 would have the same access as X1.
He's not asking how to do it using the current language; he's asking to
retain that capability in the event such a change is approved. Perhaps a
"stranger" keyword? :-)

(I've no opinion yet on this issue).

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B932D74.721682AA@iobox.com>, Sergey P. Derevyago <non-
existent@iobox.com> writes
>> Now how, without breaking encapsulation, do you provide Y::Y1::Pimpl
>> with access to Y's private/protected parts?
>       Do you really think that Y::Y1::Pimpl must be the friend of Y? As for
>me,
>I really doubt it. For example, Y::Y1 can be the friend of both Y and
>Y::Y1::Pimpl for the almost the same results. In particular D&E shows us
>that some features can not be accepted if they are intended to support a
>poor style programming.

I do not see this, friendship is not a transitive operation.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
> >> Now how, without breaking encapsulation, do you provide Y::Y1::Pimpl
> >> with access to Y's private/protected parts?
> >       Do you really think that Y::Y1::Pimpl must be the friend of Y?
> > As for me, I really doubt it. For example, Y::Y1 can be the friend
> > of both Y and Y::Y1::Pimpl for the almost the same results.
> I do not see this, friendship is not a transitive operation.
 Thanks, but I have known this for about ten years.

 I've just said that Y:Y1 can access the guts of both Y and Y::Y1::Pimpl:

// file1.cpp
 class Y {
       class Y1;
       friend class Y1;

  public:
       // ...
 };

// file2.cpp
 class Y::Y1 {
       struct Pimpl {
              int a;
       };

       Pimpl* pimpl;  // hidden representation,
                      // sizeof(Y::Y1)==sizeof(Pimpl*)
  public:
       // ...

       void setA(int a_) { pimpl->a=a_; }
       int  getA()       { return pimpl->a; }
 };

You don't have to hide the implementation of Y::Y1::Pimpl from Y::Y1,
because the (public) definition of Y lives in the separate file. And you
don't have to access the Y's guts from Y::Y1::Pimpl -- you can do it from
Y::Y1. Moreover: Y::Y1::Pimpl is an implementation detail of Y::Y1 and Y
don't have to know about it at all: what if I'll define Y::Y1::Pimpl_2,
Y::Y1::Pimpl_3, Y::Y1::Pimpl_4 next week?
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B947D5D.36ECA7C7@iobox.com>, Sergey P. Derevyago <non-
existent@iobox.com> writes
>You don't have to hide the implementation of Y::Y1::Pimpl from Y::Y1,
>because the (public) definition of Y lives in the separate file. And you
>don't have to access the Y's guts from Y::Y1::Pimpl

Really? Are you sure about that? Why should I clutter my definition of
Y1 with relay functions to allow Y::Y1::Pimpl access to Y's guts?

>-- you can do it from
>Y::Y1. Moreover: Y::Y1::Pimpl is an implementation detail of Y::Y1 and Y
>don't have to know about it at all: what if I'll define Y::Y1::Pimpl_2,
>Y::Y1::Pimpl_3, Y::Y1::Pimpl_4 next week?

And that is exactly the point. If we no longer have to grant friendship
inwards, it does not matter. Y does not need to know about helper
classes in Y1 (to whatever nesting depth the implementor of Y1 finds
convenient.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B92B7F4.DAAC2487@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>> class X {
>>    class X1 {
>>    friend class X;
>>    ...
>>    };
>>    class X2 {
>>    ...
>>    };
>> };
>>
>> class X2 has no access to the private parts of class X1 though X has.
>
>If such a change were made, X2 would have the same access as X1.

I think the intention is that this will not be the case. But until
actual words are available we are free to select the behaviour we want.
The thing I, and many others who have worked on this part of the
Standard are convinced of is that the classical position is a cause of
problems and that we should not attempt to restore it.

If we had never had the classic requirement I doubt that anyone would
propose it now. It seems clear that any requirement for inward granting
of friendship requires outer scopes to have knowledge of the
implementation details of inner scopes. That interferes with
implementation hiding techniques.


>He's not asking how to do it using the current language; he's asking to
>retain that capability in the event such a change is approved. Perhaps a
>"stranger" keyword? :-)

And we do not need a new keyword, only careful wordsmithing to ensure
that two classes in the same scope do not have access to each other
private data unless they explicitly grant friendship to each other.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>
> >
> >> If you need to partition your data into mutually
> >> exclusive blocks then you can do so with two nested classes (with their
> >> data private. One can grant friendship to the enclosing class if that
> >> helps your design.
> >       And do the 40 language experts really think that it's much more easy to
> >define an additional inner class rather than not to say "friend
> >Outer::Inner;"?
>
> Yes because of the problems of:
>
> class Y {
>   class Y1; //forward declaration
>   ...
> };
>
> class Y::Y1 {
>   struct Pimpl;
>   ...
> };
>
> Now how, without breaking encapsulation, do you provide Y::Y1::Pimpl
> with access to Y's private/protected parts? Indeed, as you are not
> allowed to forward declare nested classes other than in the definition
> of the enclosing class, this requires that Y::Y1 be defined within the
> definition of Y.

Well, by allowing:

class Y {
  class Y1; //forward declaration
  friend class Y::Y1; // Should "friend class Y1" here mean the nested
class or a top-level Y1?
  ...
};

Which is a smaller change than automatically making nested classes
friends.  Clearly this was considered and rejected -- why?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Is the following code well-formed? I think it is, but Comeau C++ says
it isn't:

  class C {
  private:
      class Nested_1 {};

      class Nested_2 {
      public:
          void f( Nested_1* );
      };
  };

Comeau (online):
  "23293.c", line 7: error: class "C::Nested_1" is inaccessible
        void f( Nested_1* );
             ^

The standard says:

  <begin quote>
      11 [class.access] clause 1:
      A member of a class can be
      - private: that is, its name can be used only by members and
      friends of the class in which it is declared.
  <end quote>

But nested classes are members of their enclosing class:

  <begin quote>
      9.2 [class.mem] clause 1:
      [...] Members of a class are data members, member functions (9.3),
      nested types, and enumerators.
  <end quote>

Any comments?
Thanks,
Ren

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <vlzo8jovm6.fsf@telgt.cs.uu.nl>, Ren=E9 van Oostrum
<rene+gnus@cs.uu.nl> writes
>Is the following code well-formed? I think it is, but Comeau C++ says
>it isn't:
>
>  class C {
>  private:
>      class Nested_1 {};
>
>      class Nested_2 {
>      public:
>          void f( Nested_1* );
>      };
>  };
>
>Comeau (online):
>  "23293.c", line 7: error: class "C::Nested_1" is inaccessible
>        void f( Nested_1* );
>             ^
>
>The standard says:
>
>  <begin quote>
>      11 [class.access] clause 1:=20
>      A member of a class can be
>      - private: that is, its name can be used only by members and
>      friends of the class in which it is declared.
>  <end quote>
>
>But nested classes are members of their enclosing class:
>
>  <begin quote>
>      9.2 [class.mem] clause 1:=20
>      [...] Members of a class are data members, member functions (9.3),
>      nested types, and enumerators.
>  <end quote>
>
>Any comments?

Yes, you did not read enough. In fact this is an area where there is a
most unfortunate error in the standard.=20

The current position is that nested classes have no privileged access to
the private and protected parts of the enclosing class. This is as it
has always been (for historical reasons). However the standard also only
allows friendship to be granted outwards or sideways, but not inward.
That is an error that we are currently tackling. The current most likely
solution is to allow nested classes access to the enclosing class
private & protected members.

For now, the enclosing class must explicitly grant friendship to nested
classes, and all compilers honour that.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ren    van Oostrum" <rene+gnus@cs.uu.nl> wrote in message
news:vlzo8jovm6.fsf@telgt.cs.uu.nl...
> Is the following code well-formed? I think it is, but Comeau C++ says
> it isn't:
>
>   class C {
>   private:
>       class Nested_1 {};
>
>       class Nested_2 {
>       public:
>           void f( Nested_1* );
>       };
>   };
>
> Comeau (online):
>   "23293.c", line 7: error: class "C::Nested_1" is inaccessible
>         void f( Nested_1* );
>              ^
>
> The standard says:
>
>   <begin quote>
>       11 [class.access] clause 1:
>       A member of a class can be
>       - private: that is, its name can be used only by members and
>       friends of the class in which it is declared.
>   <end quote>
>
> But nested classes are members of their enclosing class:
>
>   <begin quote>
>       9.2 [class.mem] clause 1:
>       [...] Members of a class are data members, member functions (9.3),
>       nested types, and enumerators.
>   <end quote>
>

Sounds like compiler schizophrenia. gcc and MSVC both accept that code as
valid.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
> has always been (for historical reasons). However the standard also only
> allows friendship to be granted outwards or sideways, but not inward.
> That is an error that we are currently tackling. The current most likely
> solution is to allow nested classes access to the enclosing class
> private & protected members.
 Don't do it!!! This is the most awful solution!

 In particular, I heavily use inner classes in Java and the unrestritced
access to the enclosed scope hurts me too much. If fact, it breaks all the
encapsulation, it's just like the inner functions nightmare which we don't
have in C/C++ :)
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3b8d4464$0$14920@news.denver1.Level3.net>, Justin Randall
<jrandall@verant.com> writes
>Sounds like compiler schizophrenia. gcc and MSVC both accept that code as
>valid.

In that case they are both technically broken or are using time
machines. The rule that caused rejection has always been that way even
if we are considering changing it.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

>> The current position is that nested classes have no privileged access to
>> the private and protected parts of the enclosing class. This is as it
>> has always been (for historical reasons). However the standard also only
>> allows friendship to be granted outwards or sideways, but not inward.
>> That is an error that we are currently tackling. The current most likely
>> solution is to allow nested classes access to the enclosing class
>> private & protected members.

Allowing private & protected access to nested classes members seems
appalling.

>> For now, the enclosing class must explicitly grant friendship to nested
>> classes, and all compilers honour that.

What is wrong with that as a solution?

Thanks

Stephen Howe



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Sergey P. Derevyago" wrote:
>
> Francis Glassborow wrote:
> > has always been (for historical reasons). However the standard also only
> > allows friendship to be granted outwards or sideways, but not inward.
> > That is an error that we are currently tackling. The current most likely
> > solution is to allow nested classes access to the enclosing class
> > private & protected members.
>         Don't do it!!! This is the most awful solution!
>
>         In particular, I heavily use inner classes in Java and the unrestritced
> access to the enclosed scope hurts me too much. If fact, it breaks all the
> encapsulation, it's just like the inner functions nightmare which we don't
> have in C/C++ :)

But in Java there's the additional twist that an object whose type is a
non-static inner class is always contained in an object of the outer
class, and can access fields and methods of the containing object
without any qualifier:

class Outer
{
int i;
class Inner
 {
 void f()
  {
  i = 3; // sets i in containing object!
  }
 }
}

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

| In article <3b8d4464$0$14920@news.denver1.Level3.net>, Justin Randall
| <jrandall@verant.com> writes
| >Sounds like compiler schizophrenia. gcc and MSVC both accept that code as
| >valid.
|
| In that case they are both technically broken or are using time
| machines. The rule that caused rejection has always been that way even
| if we are considering changing it.

In the case of GCC, it is a deliberate decision: in an attempt to
implement the proposed resolution.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Justin Randall" <jrandall@verant.com> writes:

[...]

| Sounds like compiler schizophrenia. gcc and MSVC both accept that code as
| valid.

GCC does accept the code because it implements the proposed resolution.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B8DEB7F.7FAB350@iobox.com>, Sergey P. Derevyago <non-
existent@iobox.com> writes
>Francis Glassborow wrote:
>> has always been (for historical reasons). However the standard also only
>> allows friendship to be granted outwards or sideways, but not inward.
>> That is an error that we are currently tackling. The current most likely
>> solution is to allow nested classes access to the enclosing class
>> private & protected members.
>       Don't do it!!! This is the most awful solution!
>
>       In particular, I heavily use inner classes in Java and the unrestritced
>access to the enclosed scope hurts me too much. If fact, it breaks all the
>encapsulation, it's just like the inner functions nightmare which we don't
>have in C/C++ :)

In a room of over 40 language experts exactly two wanted to retain the
historical position. If you need to partition your data into mutually
exclusive blocks then you can do so with two nested classes (with their
data private. One can grant friendship to the enclosing class if that
helps your design.

Martin O'Riordan has a detailed paper explaining why the historical rule
breaks encapsulation (because friendship is not transitive, outer
classes can find they need knowledge of inner classes implementation
details where helper classes are being used inside the inner class.)



Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3b8e87bc$0$8508$ed9e5944@reading.news.pipex.net>, Stephen
Howe <SPAMstephen.howeGUARD@tnsofres.com> writes
>Allowing private & protected access to nested classes members seems
>appalling.

Why? What is proposed is that nested classes have access to the members
of the enclosing class, something different from what you are thinking
(I hope)


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]