In article <JSS.94May24161205@summit.lucid.com>, jss@lucid.com (Jerry Schwarz) writes:
> In article <2rtoic$19o@tango.ics.uci.edu> schmidt@tango.ics.uci.edu (Douglas C. Schmidt) writes:
>
>            I'm experiencing different behavior from different C++
>    compilers with respect to the following use of nested classes.  Let's
>    say that I have a set of classes as follows:
>
>
>    ----------------------------------------
>    class OuterClass
>    {
>    public:
>            // ...
>    private:
>
>            struct InnerStruct
>            {
>                    // ...
>            };
>
>            class InnerClass
>            {
>            public:
>                    int Foo (InnerStruct *);
>                    // ...
>            };
>
>    };
>
>    int OuterClass::InnerClass::Foo (OuterClass::InnerStruct *s)
>    {
>            // ...
>    }

> [I corrected a couple of typos in the original posting.]
>
> The working paper says (11[class.access])
>
>         A member of a class can be
>            -- private : that is, its name can be used
>                 only by member functions and friends of the classs
>                 in which it is declared.
>
> I believe that there is general agreement of the committee that in
> this context "member" includes all names (including types and
> enumerators) declared within the class.  There is some sentiment that
> nested classes (such as InnerClass) ought to automatically be friends
> of their containing class, but the current working paper does not
> contain such a rule.
>
> So, at least on my reading of the current working paper Lucid is
> correct in complaining about the use of OuterClass::InnerStruct as an
> argument to a member of OuterClass::InnerClass.
>
>   -- Jerry Schwarz(jss@lucid.com)
>
>
To second this, the ARM also has section that basically says that
nested classes don't have special access rights. This also supports
the claim that OuterClass::InnerStruct is not accessible from
OuterClass::InnerClass.

--
+==============================|==============================+
| Hartmut Kocher               |                              |
| Technical Consultant         | All opinions expressed here  |
| Rational GmbH                | are my own.                  |
| Rosenstrasse 7               |                              |
| 82049 Pullach im Isartal     | I know you guessed it,       |
| Germany                      | but it keeps my lawyer happy.|
| Email: hwk@rational.com      |                              |
+==============================|==============================+

Hi,

 I'm experiencing different behavior from different C++
compilers with respect to the following use of nested classes.  Let's
say that I have a set of classes as follows:

----------------------------------------
class Outer
{
public:
 // ...
private:

 struct InnerStruct
 {
  // ...
 };

 class InnerClass
 {
 public:
  int Foo (InnerStruct *);
  // ...
 };

};

int OuterClass::InnerClass::foo (OuterClass::InnerStruct *s)
{
 // ...
}
----------------------------------------

This compiles just fine using cfront-based compilers (e.g., SunC++ 3.x
and Centerline 2.x).  However, Lucid C++ complains that
OuterClass::InnerStruct is private.  Is this interpretation correct
with respect to the emerging ANSI C++ draft standard?

 Thanks,

  Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4105

In article <2rtoic$19o@tango.ics.uci.edu> schmidt@tango.ics.uci.edu (Douglas C. Schmidt) writes:

           I'm experiencing different behavior from different C++
   compilers with respect to the following use of nested classes.  Let's
   say that I have a set of classes as follows:


   ----------------------------------------
   class OuterClass
   {
   public:
           // ...
   private:

           struct InnerStruct
           {
                   // ...
           };

           class InnerClass
           {
           public:
                   int Foo (InnerStruct *);
                   // ...
           };

   };

   int OuterClass::InnerClass::Foo (OuterClass::InnerStruct *s)
   {
           // ...
   }
   ----------------------------------------

   This compiles just fine using cfront-based compilers (e.g., SunC++ 3.x
   and Centerline 2.x).  However, Lucid C++ complains that
   OuterClass::InnerStruct is private.  Is this interpretation correct
   with respect to the emerging ANSI C++ draft standard?

[I corrected a couple of typos in the original posting.]

Cfront has absolutely no notion of private nested classes.  Go ahead,
try to get a "privacy usage" error on any use of InnerStruct in any
context.  You'll find you can't.  If that is what you want, just put
the class definitions in the public section.

The working paper says (11[class.access])

        A member of a class can be
           -- private : that is, its name can be used
                only by member functions and friends of the classs
                in which it is declared.

I believe that there is general agreement of the committee that in
this context "member" includes all names (including types and
enumerators) declared within the class.  There is some sentiment that
nested classes (such as InnerClass) ought to automatically be friends
of their containing class, but the current working paper does not
contain such a rule.

So, at least on my reading of the current working paper Lucid is
correct in complaining about the use of OuterClass::InnerStruct as an
argument to a member of OuterClass::InnerClass.

  -- Jerry Schwarz(jss@lucid.com)