i_hate_spam@hotmail.com ("Bo-Staffan Lankinen") wrote (abridged):
> > I suspect you'd need to include the access specifier in the forward
> > declaration, which is a bit ugly:
> >
> >    struct Outer;
> >    struct Outer:: public Inner; // Or whatever.
>
> That could be solved by not doing any access-checking at all when
> creating/manipulating pointers to a nested class (or nested type). I
> don't think that violates the original intention of the access-rights.

I think that would be a bigger change to the language, in that it changes
the meaning of existing code. The implications of that are harder to
fathom.

It's very useful to be able to pass around references and pointers to
incomplete types. It is also useful to be able to restrict access to such.

-- Dave Harris, Nottingham, UK

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

stephen.clamage@sun.com (Steve Clamage) wrote in message news:<ci4ugc$2h4$1@news1nwk.SFbay.Sun.COM>...
> Tom Tanner wrote:
> > It would be nice if C++ allowed forward definition of nested classes -
> > currently it doesn't, and it seems rather an un-necessary restriction.

    <snip>

> > Just a simple declaration
> >
> > class Container;
> > class Container::Iterator;
> >
> > would be enough, and I can't see it being syntactically confused with
> > anything else (pace having a namespace called Container of course).
>
> The design criteria for classes is that the complete contents of the
> class are declared in the class.
>
> This approach would allow extending the class without touching the
> class declaration, and unknown to the owner of the class. With the
> current rule, it is sufficient to include the header that declares the
> class to ensure that all parts of the program see the same class
> declaration.
    <snip>
> ---
> Steve Clamage, stephen.clamage@sun.com

    A nested class is not really in the "contents" of the class.
    Making a class nested only adds access restrictions and name
    qualification.

    The complaint about "extending" a class applies whether or not
    the class is nested.  If class A and class B are closely related,
    a change in one is going to "extend" (or break) the other, and
    that's true whether you call them A and B or A and A::B.


    Aside from access, I don't see how a nested class brings up
    any issues that aren't present with two classes that aren't
    nested.


    As for access, I think worries that forward declaration of
    nested classes violates access restrictions are overblown.

    Remember, class A::B only defines an incomplete class.
    You can't create, destroy, or operate on an instance without the
    full definition.   Moreover, it seems reasonable to say
    that A::B isn't fully defined unless A is, at which point
    the compiler will see whether A::B is private to A.

    I don't think that the ability to pass around (but not create
    or process) a pointer/reference to a private type is a
    serious subversion of the access system.  (You can do that
    much even if A::B isn't defined anywhere!)

    In fact, I can see uses for allowing a pointer to A::B to
    be passed around by code that isn't allowed to otherwise
    directly access it -- I'd call it an "opaque pointer."
    Class A can generate the pointer, the user passes it around,
    but has to go back to class A to do anything useful with it.
    This means that A::B can be changed at any time without
    the user having to recompile.

    On the other hand, if A doesn't provide a way to get an
    instance of A::B, then I'm left with just a name.  I can
    declare a pointer to A::B, but the only legal value I can
    use is (A::B *)0.


    The thing is, the OP and I (and others?) have real applications
    where allowing forward declaration of nested classes would
    make our code better (more expressive, less coupling, etc.)

    In this thread, and in responses to my own postings on the
    subject, I have only seen rather abstract objections, to the
    point that I wonder how many of the responders have much experience
    with nested classes.  (One, in fact, says he avoids them.)

    So far, I haven't seen an explanation as to how allowing it
    would introduce new real problems.  Examples?


-- Alan McKenney
alan_mckenney1@yahoo.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.jamesd.demon.co.uk/csc/faq.html                       ]

> The main difference is access rights. Currently this:
>
>    struct Outer {
>    private:
>        struct Inner {};
>    };
>
>    void proc( Outer::Inner *p ); // Error!
>
> won't compile because Outer::Inner is private and proc() is not a friend.
> You would need a form of forward declaration which preserves that; which
> would allow the compiler to reject:
>
>    struct Outer;
>    struct Outer::Inner;
>
>    void proc( Outer::Inner *p ); // Error?
>
> I suspect you'd need to include the access specifier in the forward
> declaration, which is a bit ugly:
>
>    struct Outer;
>    struct Outer:: public Inner; // Or whatever.

That could be solved by not doing any access-checking at all when
creating/manipulating pointers to a nested class (or nested type). I don't
think that violates the original intention of the access-rights.

Bo-Staffan


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

ttanner2@bloomberg.net (Tom Tanner) wrote (abridged):
> It would be nice if C++ allowed forward definition of nested classes -
> currently it doesn't, and it seems rather an un-necessary restriction.

I agree it would be nice. Currently I avoid nested classes (unless they
are private or protected). If there's a chance someone else will want to
use them, I make them full outer classes so they can be forward declared
without #including the main class's header.

In general I am in favour of things which help me manage source code
dependencies. Forward declarations of enums is another one.

-- Dave Harris, Nottingham, UK

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

stephen.clamage@sun.com (Steve Clamage) wrote in message news:<cif1cq$405$1@news1nwk.SFbay.Sun.COM>...
> Tom Tanner wrote:
> > stephen.clamage@sun.com (Steve Clamage) wrote in message news:<ci4ugc$2h4$1@news1nwk.SFbay.Sun.COM>...
> >>
> >>The design criteria for classes is that the complete contents of the
> >>class are declared in the class.
> >
> > Doesn't really explain why you need forward declarations at all then!
>
> I meant to say "the C++ language design criteria for classes", in case you
> thought I was talking about coding style.
>
> You can forward declare a class so that you can create pointers or references
> to it. The forward declaration says only that a type of that name is defined
> somewhere in the program. It says nothing about its contents.
>
(cut examples)
Yes, I know why you need forward declarations - however, I don't see
why the design criteria above implies you need forward declarations
but not of the sort I want.

> >
> >>[your suggestion] would allow extending the class without touching the
> >>class declaration, and unknown to the owner of the class. With the
> >>current rule, it is sufficient to include the header that declares the
> >>class to ensure that all parts of the program see the same class
> >>declaration.
> >
> > I don't think this answers the issue.
>
> I think it answers your question about why
>  class Outer::Inner;
> is not allowed. It's a type safety issue.

But it isn't a type safety issue. Forward declaring a nested class has
no effect whatsoever on the containing class, and it doesn't allow you
to extend the containing class. I'm not asking to be able to do

class Outer { ... }
class Outer::Inner { ... }

I'm asking to be able to do

class Outer;
class Outer::Inner;

...

class Outer { ...; class Inner { ... } }

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

pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0409171501.5e741407@posting.google.com>...
> ttanner2@bloomberg.net (Tom Tanner) wrote in message news:<22f7de4e.0409170702.1b080d84@posting.google.com>...
> > pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0409160817.6bdd9007@posting.google.com>...
>
> [...]
>
> > > class Outer
> > > {
> > >     typedef Outer_inner Inner;
> > > };
> >
> > Well, that's a thought which I might be able to proceed with. It has
> > to be said however, that it would be nicer (considering the STL
> > paradigm of making iterators be nested classes of the container over
> > which they iterate) if the language allowed you just to say what you
> > meant, rather than relying on that sort of workround, which is
> > /slightly/ better than the one I have currently.
>
> The workaround is, in some cases, better than the solution:
>
(cut workround, which doesn't look any better than the solution)
> (The STL does not, in fact, require iterators to be nested classes,
> although this is a typical implementation.)

paradigm != requirement - I do know it isn't required, but it is done
so often, that if one wishes to make an STL-style container, one
invariably has to nest the iterators in the classes in order not to
confuse other users of the container, rather than any STL or language
constraints.

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

ttanner2@bloomberg.net (Tom Tanner) wrote in message news:<22f7de4e.0409200305.28af716b@posting.google.com>...
> pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0409171501.5e741407@posting.google.com>...
> >
> > The workaround is, in some cases, better than the solution:
> >
>  (cut workround, which doesn't look any better than the solution)

I'm not sure whether you got the point. The "workaround" works when
you want to use the nested type in a deduced context, whereas the
"solution" does not. Which one looks better is not an issue.

> > (The STL does not, in fact, require iterators to be nested classes,
> > although this is a typical implementation.)
>
> paradigm != requirement - I do know it isn't required, but it is done
> so often, that if one wishes to make an STL-style container, one
> invariably has to nest the iterators in the classes in order not to
> confuse other users of the container, rather than any STL or language
> constraints.

The users don't care where the type is actually defined. They only
require the ability to refer to it using the Container::iterator
notation, which is provided.

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

stephen.clamage@sun.com (Steve Clamage) wrote in message news:<ci4ugc$2h4$1@news1nwk.SFbay.Sun.COM>...
> Tom Tanner wrote:
> > It would be nice if C++ allowed forward definition of nested classes -
> > currently it doesn't, and it seems rather an un-necessary restriction.
> >
> > One place it can make life extremely difficult is when trying to
> > create an STL-like container class (where the iterators are generally
> > defined as classes nested within the container) and the contained
> > objects for various reasons require the iterator to be a friend of the
> > object.
> >
> > Just a simple declaration
> >
> > class Container;
> > class Container::Iterator;
> >
> > would be enough, and I can't see it being syntactically confused with
> > anything else (pace having a namespace called Container of course).
>
> The design criteria for classes is that the complete contents of the
> class are declared in the class.
Doesn't really explain why you need forward declarations at all then!

> This approach would allow extending the class without touching the
> class declaration, and unknown to the owner of the class. With the
> current rule, it is sufficient to include the header that declares the
> class to ensure that all parts of the program see the same class
> declaration.
I don't think this answers the issue. For various reasons I need to
> But maybe you mean you want only to forward-declare nested classes
> inside the class body, like this:
>  class outer {
>   class inner;
>   .....
>   class inner { ... }
>  };
> You can already do that, although technically you can't use that
> method to declare a nested class to be a friend.

No, this isn't the problem I need to solve.

I want to do something like:

class Outer;
class Outer::Inner;

class Thing { friend Outer::Inner; private: thingy };

class Outer
{
   class Inner
   {
      Thing thingy;
      void somefunc() { cout << thing->thingy << "\n";  }
   }
}

I've toyed around with reordering things, and taking the inline
functions into a separate header, but that has its own nightmares, and
I haven't been able to get it to work yet.

When it comes down to it, I can't see a lot of difference in
"cleanliness" between forward declaring a class and forward declaring
a nested class.

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

ttanner2@bloomberg.net (Tom Tanner) wrote in message news:<22f7de4e.0409150223.58a97b0f@posting.google.com>...
>
> I want to do something like:
>
> class Outer;
> class Outer::Inner;

class Outer_inner;

> class Thing { friend Outer::Inner; private: thingy };

class Thing { friend class Outer_inner; private: thingy };

> class Outer
> {
>    class Inner
>    {
>       Thing thingy;
>       void somefunc() { cout << thing->thingy << "\n";  }
>    }
> }

class Outer_inner
{
    Thing thingy;
    void somefunc() { cout << thing->thingy << "\n";  }
};

class Outer
{
    typedef Outer_inner Inner;
};

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

pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0409160817.6bdd9007@posting.google.com>...
> ttanner2@bloomberg.net (Tom Tanner) wrote in message news:<22f7de4e.0409150223.58a97b0f@posting.google.com>...
> >
> > I want to do something like:
> >
> > class Outer;
> > class Outer::Inner;
>
> class Outer_inner;
>
> > class Thing { friend Outer::Inner; private: thingy };
>
> class Thing { friend class Outer_inner; private: thingy };
>
> > class Outer
> > {
> >    class Inner
> >    {
> >       Thing thingy;
> >       void somefunc() { cout << thing->thingy << "\n";  }
> >    }
> > }
>
> class Outer_inner
> {
>     Thing thingy;
>     void somefunc() { cout << thing->thingy << "\n";  }
> };
>
> class Outer
> {
>     typedef Outer_inner Inner;
> };
>

Well, that's a thought which I might be able to proceed with. It has
to be said however, that it would be nicer (considering the STL
paradigm of making iterators be nested classes of the container over
which they iterate) if the language allowed you just to say what you
meant, rather than relying on that sort of workround, which is
/slightly/ better than the one I have currently.

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

Tom Tanner wrote:
> stephen.clamage@sun.com (Steve Clamage) wrote in message news:<ci4ugc$2h4$1@news1nwk.SFbay.Sun.COM>...
>>
>>The design criteria for classes is that the complete contents of the
>>class are declared in the class.
>
> Doesn't really explain why you need forward declarations at all then!

I meant to say "the C++ language design criteria for classes", in case you
thought I was talking about coding style.

You can forward declare a class so that you can create pointers or references
to it. The forward declaration says only that a type of that name is defined
somewhere in the program. It says nothing about its contents.

Without forward declarations, it would be impossible to create objects that
reference one another:
 struct parent;
 struct child { parent* myparent; };
 struct parent { std::list<child*> mychildren; };


>
>>[your suggestion] would allow extending the class without touching the
>>class declaration, and unknown to the owner of the class. With the
>>current rule, it is sufficient to include the header that declares the
>>class to ensure that all parts of the program see the same class
>>declaration.
>
> I don't think this answers the issue.

I think it answers your question about why
 class Outer::Inner;
is not allowed. It's a type safety issue.

---
Steve Clamage, stephen.clamage@sun.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.jamesd.demon.co.uk/csc/faq.html                       ]

ttanner2@bloomberg.net (Tom Tanner) wrote (abridged):
> When it comes down to it, I can't see a lot of difference in
> "cleanliness" between forward declaring a class and forward declaring
> a nested class.

The main difference is access rights. Currently this:

    struct Outer {
    private:
        struct Inner {};
    };

    void proc( Outer::Inner *p ); // Error!

won't compile because Outer::Inner is private and proc() is not a friend.
You would need a form of forward declaration which preserves that; which
would allow the compiler to reject:

    struct Outer;
    struct Outer::Inner;

    void proc( Outer::Inner *p ); // Error?

I suspect you'd need to include the access specifier in the forward
declaration, which is a bit ugly:

    struct Outer;
    struct Outer:: public Inner; // Or whatever.

Then any abuses could be caught no later than link time (eg if the
compiler uses name mangling a dumb linker could do it). You could have the
access default to "public" to avoid the ugliness in the common case.

You need to watch out for cases like:

    struct Vector_int {
    public:
    #ifdef _NDEBUG
        struct iterator; // Slow, safe.
    #else
        typedef int *iterator; // Fast, dangerous.
    #endif
    };

which is reasonable code, but difficult to forward declare for other
reasons. Typedefs can't be forward declared. (If they could, how would
overloading work?)

-- Dave Harris, Nottingham, UK

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

ttanner2@bloomberg.net (Tom Tanner) wrote in message news:<22f7de4e.0409170702.1b080d84@posting.google.com>...
> pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0409160817.6bdd9007@posting.google.com>...

[...]

> > class Outer
> > {
> >     typedef Outer_inner Inner;
> > };
>
> Well, that's a thought which I might be able to proceed with. It has
> to be said however, that it would be nicer (considering the STL
> paradigm of making iterators be nested classes of the container over
> which they iterate) if the language allowed you just to say what you
> meant, rather than relying on that sort of workround, which is
> /slightly/ better than the one I have currently.

The workaround is, in some cases, better than the solution:

template<class T> struct container1
{
    struct iterator {};
    iterator begin();
};

template<class T> struct container2_iterator {};

template<class T> struct container2
{
    typedef container2_iterator<T> iterator;
    iterator begin();
};

template<class T> void f( typename container1<T>::iterator i )
{
}

template<class T> void f( container2_iterator<T> i )
{
}

int main()
{
    container1<int> c1;
    f( c1.begin() );

    container2<int> c2;
    f( c2.begin() );
}

Note that the first call to f will not compile due to the nondeduced
context.

(The STL does not, in fact, require iterators to be nested classes,
although this is a typical implementation.)

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

Tom Tanner wrote:
> It would be nice if C++ allowed forward definition of nested classes -
> currently it doesn't, and it seems rather an un-necessary restriction.
>
> One place it can make life extremely difficult is when trying to
> create an STL-like container class (where the iterators are generally
> defined as classes nested within the container) and the contained
> objects for various reasons require the iterator to be a friend of the
> object.
>
> Just a simple declaration
>
> class Container;
> class Container::Iterator;
>
> would be enough, and I can't see it being syntactically confused with
> anything else (pace having a namespace called Container of course).

The design criteria for classes is that the complete contents of the
class are declared in the class.

This approach would allow extending the class without touching the
class declaration, and unknown to the owner of the class. With the
current rule, it is sufficient to include the header that declares the
class to ensure that all parts of the program see the same class
declaration.

But maybe you mean you want only to forward-declare nested classes
inside the class body, like this:
 class outer {
  class inner;
  .....
  class inner { ... }
 };
You can already do that, although technically you can't use that
method to declare a nested class to be a friend.

A proposal before the C++ Committee that seems certain to be adopted
is to make all class members automatically friends of all other class
members, including nested classes. With that change, you don't need
friend declarations for iterators nested in a class.

---
Steve Clamage, stephen.clamage@sun.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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ci4ugc$2h4$1@news1nwk.SFbay.Sun.COM>, Steve Clamage
<stephen.clamage@sun.com> writes
>A proposal before the C++ Committee that seems certain to be adopted is
>to make all class members automatically friends of all other class
>members, including nested classes. With that change, you don't need
>friend declarations for iterators nested in a class.

I do not think that is quite true (or I hope that what I understand from
the above isn't)

class X{
    class Y {
      // whatever
    };
    class Z {
      // whatever
    };
    // whatever
};

AIUI the intention is to allow both Y and Z to have access to the
private parts of X. However I do not think it is the intent to allow
members of X, including Y and Z to have access to the private parts of Y
and/or Z.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

It would be nice if C++ allowed forward definition of nested classes -
currently it doesn't, and it seems rather an un-necessary restriction.

One place it can make life extremely difficult is when trying to
create an STL-like container class (where the iterators are generally
defined as classes nested within the container) and the contained
objects for various reasons require the iterator to be a friend of the
object.

Just a simple declaration

class Container;
class Container::Iterator;

would be enough, and I can't see it being syntactically confused with
anything else (pace having a namespace called Container of course).

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