dev-cpp-users

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

[Michael C. <jd...@ho...>]

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

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

[Jason H. <jas...@bt...>]

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

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

[Ioannis V. <no...@ya...>]

Win32 API is old, MFC is old. .NET will have a different system call
class hierarchy called BCL (Base Class Library). So why learn legacy
stuff?

For now, if you can't wait for .NET i suggest you Borland C++ Builder
and its class hierarchy called VCL (Visual Class Library). It is a lot
higher level than MFC/Win32 crap. For accuracy it is a very high level
Win32 wrapper. It covers anything and you will probably never need to
write win32 crap. Also, Borland RAD/VCL is more high level than the
RAD/BCL which will come with Visual Studio 7 and .NET in general.
Dev-C++ does not cover of course VCL, but i am telling you the best
solution for Windows programming (the best thing for you) for now. The
book "C++ Builder 5 Developer's Guide" by Sams Publishing comes with a
trial version of the Borland's IDE and this is also the book i suggest
you read for this particular IDE.

 As for "The C++ Programming Language" 3rd  edition or special edition,
i suggest you read it all from cover to cover (although it will take
about 1-2 years). Reading for example 2-3 pages/day is a good speed,
with no much brain overhead and what you learn will not get wasted since
C++ will not change. :)


Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
* Alternative URL: http://run.to/noicys


> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Jason Hardman
> Sent: Wednesday, September 26, 2001 5:29 PM
> To: dev...@li...
> Subject: Re: [Dev-C++] C++ standard - Nesting classes.
>=20
>=20
> Perhaps I should have been a little more clearer in the=20
> wording I used. What am doing is declaring one class which is=20
> the primary class that provides the functionality I am coding=20
> (a glorified state storage object in this case), and that=20
> class has other classes declared within it. These internal=20
> class declerations are private and so it shoudn't be possible=20
> to instantiate an object from one of these classes from=20
> outside the object. The Example from Ioannis Vranos=20
> (thanks)shows this quite well.
>=20
> class A
> {
> public:
>     enum errors{MEMORY, DISK, MONITOR};
>=20
> private:
>     class E
>     {
>          errors e;
>=20
>      public:
>          E(errors er):e(er) {}
>     };
>=20
> };
>=20
> int main()
> {
>  A a;
>=20
>  A::errors e;
>=20
>  A::E x(e); // Mistake, E is private
> }
>=20
> This compiles under Dev - C++ with MinGW, but not with=20
> Borland C++ 5.5.
>=20
> Declaring a class doesn't create an instance of it, but AFAIK=20
> it should still be subject to the access specifier it was=20
> declared under. This is probably a known issue for MinGW,=20
> although I haven't had a chance to check that yet.
>=20
> By the way, I already have Bjarn Stroustrup's book. I already=20
> knew how to code in C++ before getting it so never really=20
> read it all the way through, but I use it whenever I want=20
> know about the best approach to a design. It has a lot of=20
> useful information although there are easier books to use as=20
> a reference.
>=20
> I have very little experience of Windows programming myself,=20
> but that something else I am trying to learn at this point.=20
> Any suggestions by anyone as to a good Windows API book would=20
> be appreciated by the way. Whenever I find a Windows book it=20
> is primarily about using MFC to write windows programs, but I=20
> don't have access to MFC at the moment so it's pretty useless to me.
>=20
> Thanks all, Jason.
>=20
> PS: sorry about blathering on and on, I do that alot. :-D
>=20
> ----- 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.
>=20
>=20
> > Hi Jason,
> >
> > The standard states that anything in your private area is only=20
> > accessable
> by
> > that class. Not even public derived classes of that class=20
> can access=20
> > it.
> >
> > The protected area is accessable by public derived classes of that=20
> > class.
> In
> > effect it becomes the private area of that derived class. Also,=20
> > classes of the same type that get passed into an object as=20
> an argument=20
> > 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=20
> > classes. For more info get Stroustrups book.
> >
> > http://www.research.att.com/~bs/
> >
> > I would not usually have a class called main, I would=20
> normally have a
> public
> > static main() function and tell my compiler which class contains=20
> > main(). However, I guess this changes when you are Windows=20
> programming=20
> > of which I have no experience.
> >
> > Could you send an example of what you are doing so we could=20
> 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=20
> classes within=20
> > >a main class that provides an overall functionality. I=20
> wanted to make=20
> > >these internal classes inaccessible to anyone using the=20
> main class. I=20
> > >had hoped that putting them in a private or protected area of the=20
> > >main class it
> would
> > >stop outside access, but this doesn't seem to work in Dev-C++=20
> > >(MinGW).
> Does
> > >anyone know if that is standard C++ behaviour? None of my=20
> C++ books=20
> > >say anything about access specifiers and nested classes,=20
> and they say=20
> > >pretty little about nested classes full-stop. It could=20
> reasonally be=20
> > >that only data and methods are affected by access specifiers, but=20
> > >it's hard for me to be sure.
> > >
> > >I am now looking for an alternative way of hiding those classes,=20
> > >although
> I
> > >have found some interesting options in using an implementation=20
> > >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=20
> > http://explorer.msn.com/intl.asp
> >
> >
> > _______________________________________________
> > Dev-cpp-users mailing list Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>=20
>=20
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>=20