Quote:Original post by yahastu
It seems that the designers of the Standard Template Library completely disagree with you!

Well, a few answers to this.

1. As others have mentioned, for some containers it's necessary.
2. The STL has many implementations. Making it a free class would have forced an implementation decision on all of them.
But, the important one...

YES! The designers of the C++ Standard Library made a lot of BAD DECISIONS. They weren't bad decisions given the information they had at the time, but proper usage style has shifted since then, and as a result there are a lot of embarassments in the standard library. That doesn't mean that it's a bad idea to use the STL; the embarassments are generally of the aesthetic rather than functional variety, and the fact that it's standardized counts for a lot more than the embarassments. But it does mean that it's generally a bad idea to look to the Standard Library for guidance on what good C++ looks like or acts like.

Quote:Original post by Sneftel
There is one gigantic difference: inner classes can access private class members. That means that an inner class can communicate with its outer class without having to go through the outer class' public interface. Because of this, making a class an inner class should be thought of as increasing the size of the class (a bad thing) while complicating its responsibilities (also a bad thing). Because of this, a class should be an inner class ONLY where it cannot reasonably be implemented using the outer class' public interface.

I doubt that an inner class actually increases the compiled size of the outer class instances, so if by "size" you refer to complexity, then you complexity of a nested class combination is really not greater than the complexity of the 2 classes separately...so I do not see any merit to your statement that "it is bad."

It does not complicate the responsibilities, it just groups those common responsibilities into the same place so that they are less likely to make an error...you're just suggesting that logically connected code should be made completely separate? Isn't that what is called "spaghetti" ? How is that good?

Often times I use an internal node struct (or similar) that I do not want the user of the class to see or instantiate directly. Hiding it inside the base class works perfectly, and is no more complicated at all. Yes I do see it as "part" of the class...because it really IS part of the class, and thats the way it should be! There is no "generic node" and I cant think of any advantage to declaring a million ungrouped "X_node" and "Y_node" in public scope.

Quote:Original post by iMalc
Or are you talking about placing the sub-object class definition inside the definition of the class that uses it?

I do mean this. What else can I refer to? :)

Quote:Original post by yahastu
It does not complicate the responsibilities, it just groups those common responsibilities into the same place so that they are less likely to make an error...you're just suggesting that logically connected code should be made completely separate? Isn't that what is called "spaghetti" ? How is that good?

Often times I use an internal node struct (or similar) that I do not want the user of the class to see or instantiate directly. Hiding it inside the base class works perfectly, and is no more complicated at all. Yes I do see it as "part" of the class...because it really IS part of the class, and thats the way it should be! There is no "generic node" and I cant think of any advantage to declaring a million ungrouped "X_node" and "Y_node" in public scope.

I do agree with you. I think nested definition is a perfect mechanism provided by cpp that you personally want to express the ideal that something won't logically make much sense if it was used by others except its outer class.

Quote:Original post by yahastu

Quote:Original post by Sneftel
There is one gigantic difference: inner classes can access private class members. That means that an inner class can communicate with its outer class without having to go through the outer class' public interface. Because of this, making a class an inner class should be thought of as increasing the size of the class (a bad thing) while complicating its responsibilities (also a bad thing). Because of this, a class should be an inner class ONLY where it cannot reasonably be implemented using the outer class' public interface.

I doubt that an inner class actually increases the compiled size of the outer class instances, so if by "size" you refer to complexity, then you complexity of a nested class combination is really not greater than the complexity of the 2 classes separately...so I do not see any merit to your statement that "it is bad."

By size I refer to the length of the source code. For code which does not significantly segregate responsiblities, the difficulty of maintaining the code tends to grow quadratically with size, so it's important. Separating the classes provides that segregation.

Quote:Often times I use an internal node struct (or similar) that I do not want the user of the class to see or instantiate directly.

Consider: Do you want your AI code to see your texture-related classes? If not, how do you prevent them from doing so?

first time poster here...

what i use nested classes for, mainly, is to impliment a base/interface class. i have a factory class that contains the implimentations for a public base class, and methods of the factory return derived objects (the nested classes) as base class pointers (pretty basic stuff).

nested enums and C Structs to me are used for either scoping in the class namespace, or for structs i often use them to wrap up data for internal arguments passing. im currently working on a C++ wrapper library for a C library (portmidi, to be more specific), and im using everything i mentioned above to help in hiding the user un-friendly C interface behind a more modern C++ interface.