Re: [Dev-C++] C++ standard - Nesting classes.

Perhaps I should have been a little more clearer in the wording I used. What
am doing is declaring one class which is the primary class that provides the
functionality I am coding (a glorified state storage object in this case),
and that class has other classes declared within it. These internal class
declerations are private and so it shoudn't be possible to instantiate an
object from one of these classes from outside the object. The Example from
Ioannis Vranos (thanks)shows this quite well.

class A
{
public:
    enum errors{MEMORY, DISK, MONITOR};

private:
    class E
    {
         errors e;

     public:
         E(errors er):e(er) {}
    };

};

int main()
{
 A a;

 A::errors e;

 A::E x(e); // Mistake, E is private
}

This compiles under Dev - C++ with MinGW, but not with Borland C++ 5.5.

Declaring a class doesn't create an instance of it, but AFAIK it should
still be subject to the access specifier it was declared under. This is
probably a known issue for MinGW, although I haven't had a chance to check
that yet.

By the way, I already have Bjarn Stroustrup's book. I already knew how to
code in C++ before getting it so never really read it all the way through,
but I use it whenever I want know about the best approach to a design. It
has a lot of useful information although there are easier books to use as a
reference.

I have very little experience of Windows programming myself, but that
something else I am trying to learn at this point. Any suggestions by anyone
as to a good Windows API book would be appreciated by the way. Whenever I
find a Windows book it is primarily about using MFC to write windows
programs, but I don't have access to MFC at the moment so it's pretty
useless to me.

Thanks all, Jason.

PS: sorry about blathering on and on, I do that alot. :-D

----- Original Message -----
From: "Michael Codadeen" <jd...@ho...>
To: <dev...@li...>
Sent: Wednesday, September 26, 2001 8:39 AM
Subject: Re: [Dev-C++] C++ standard - Nesting classes.


> Hi Jason,
>
> The standard states that anything in your private area is only accessable
by
> that class. Not even public derived classes of that class can access it.
>
> The protected area is accessable by public derived classes of that class.
In
> effect it becomes the private area of that derived class. Also, classes of
> the same type that get passed into an object as an argument may have their
> protected area accessed.
>
> i.e.
>
> Class A {
> public:
>    inline mthd(Class A& obj){cout << obj.data << endl;};
> protected:
>    data;
> }
>
> Class A a, b;
> a.mthd(b); << object a can access b protected area.
>
> The public area of a class can be accessed by anyone.
>
> The story is slightly different for protected and private derived classes.
> For more info get Stroustrups book.
>
> http://www.research.att.com/~bs/
>
> I would not usually have a class called main, I would normally have a
public
> static main() function and tell my compiler which class contains main().
> However, I guess this changes when you are Windows programming of which I
> have no experience.
>
> Could you send an example of what you are doing so we could help some
more.
>
> Thanks,
>
> Michael
>
> >From: "Jason Hardman" <jas...@bt...>
> >Reply-To: dev...@li...
> >To: "Dev-C++" <dev...@li...>
> >Subject: [Dev-C++] C++ standard - Nesting classes.
> >Date: Wed, 26 Sep 2001 03:03:24 +0100
> >
> >Hi,
> >
> >In a project I have been working on I have nested some classes within a
> >main
> >class that provides an overall functionality. I wanted to make these
> >internal classes inaccessible to anyone using the main class. I had hoped
> >that putting them in a private or protected area of the main class it
would
> >stop outside access, but this doesn't seem to work in Dev-C++ (MinGW).
Does
> >anyone know if that is standard C++ behaviour? None of my C++ books say
> >anything about access specifiers and nested classes, and they say pretty
> >little about nested classes full-stop. It could reasonally be that only
> >data
> >and methods are affected by access specifiers, but it's hard for me to be
> >sure.
> >
> >I am now looking for an alternative way of hiding those classes, although
I
> >have found some interesting options in using an implementation namespace,
I
> >am still interesting in hearing any other ideas?
> >
> >Thanx, Jason.
> >
> >
> >_______________________________________________
> >Dev-cpp-users mailing list
> >Dev...@li...
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users