Which is The Best Way To Do It ???

[Braulio Dez]

Hi, Nested classes are quite heavy used in MFC, If I´m not wrong ( or if the things haven´t change this times :-) ), for example is how MFC creates COM objects ( the macros for the interfaces, declare just nested classes), so I think it´s ok. HTH Braulio

[Mazdak]

Jon Hulatt wrote: Is this a good idea? why not? Mazy "So,so you think you can tell, Heaven from Hell, Blue skies from pain,... How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975

[Not Active]

I think it is more a style thing. Unless it is a very small class utility class I don't like to nest classes. Makes it harder to read otherwise. Just my opinion though.

[Joaquin M Lopez Munoz]

You don't prevent third code from creating CMySecondCLasses just by defining it into CMyFirstClass. It is required also that:

1. The nested class lies in the private part of the nesting class,
2. or the constructors for the nested class are private and the nesting class is a friend of the nested class

Apart from this, nesting it is an excellent way to restrict visiblity and show design dependencies between classes (IMHO). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

[Jon Hulatt]

The declaration of the second class is within a protected: section. Doesn't really bother me if technically i could create an instance of the second class elsewhere, it's definately more of a design and organisation thing. I just wondered if i was overlooking some limitation or side effect of class nesting. Obviously not, great! Sorry to dissapoint you all with my lack of a witty or poignant signature.

[Nish Nishant]

I do a good deal of nesting, though I nest structs within classes rather than classes within classes :-) Nish My most recent CP article :- A newbie's elementary guide to spawning processes www.busterboy.org

[Jon Hulatt]

thanks nish. although it's got to be a class, because it has member functions and things. besides, what's the difference between a struct anyway? And I like the whole nested classes thing. it makes things more confusing for the uninitiated. Which makes me feel cleverer. Does anyone else here secretly enjoy it when they come up with something really complicated that noone else will ever make head or tail of? ;-) Sorry to dissapoint you all with my lack of a witty or poignant signature.

[Tim Smith]

Does anyone else here secretly enjoy it when they come up with something really complicated that noone else will ever make head or tail of? :laugh: No, because every time I do something like that, I am the one who can't make heads or tails out of it 2 months later. :laugh: Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

[Paul M Watt]

A struct and a class are basically the same thing in c++, however a struct defaults all of its members to public and the classes default declaration is private. Other than that you can inherit and do all of the things that you can do from a class, with a struct.

[Paul M Watt]

Jon Hulatt wrote: Does anyone else here secretly enjoy it when they come up with something really complicated that noone else will ever make head or tail of? I enjoy it, but I also enjoy trying to explain to someone what I actually did, and try to help them understand it, then they get a deeper appreciation for some of the code that I develop.

[RaviBee]

Jon Hulatt wrote: Does anyone else here secretly enjoy it when they come up with something really complicated that noone else will ever make head or tail of? I prefer hearing that my code and interfaces are clear and easy to understand. Code that is extremely hard to understand is usually an indication of poor design. /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com

[Stephen C Steel]

Theres nothing wrong with nested classes. If CMySecondClass is only meaningful in the context of a CMyFirstClass object, then nesting the classes makes this clear.

However, if the second class is an implementation detail that doesn't appear in the public interface, there is another technique that you may be able to apply. In the header file that declares CMyFirstClass you simply give a forward reference to CMySecondClass:

class CMySecondClass; // forward declaration

class CMyFirstClass
{
public:
// public interface (CMySecondClass not mentioned)

protected:
CMySecondClass *m_p_instance;

//protected or private member functions
//which may include arguments of type
//(CMySecondClass *) or (CMySecondClass&)
};

Now, both the declaration and implementation of CMySecondClass can be put in the implementation file for CMyFirstClass. This provides much stronger encapsulation than a nested protected or private class, since the details of CMySecondClass aren't even visible to code that uses CMyFirstClass (other than the fact that CMySecondClass exists). With a nested protected or private class, the details of CMySecondClass are visible, but access is restricted. Stephen C. Steel Kerr Vayne Systems Ltd.