Downside of nested classes.
Posted: December 8th, 2017, 8:36 pm
Nested classes are nice, they get to have unrestricted access to parent members and keeps code separate and together at the same time.
Take chili's Event classes in the Keyboard and Mouse classes. He can reuse the name Event because each is in the scope of the their respective parent classes making Event more like Keyboard::Event and Mouse::Event. This keeps from having to name those classes KeyboardEvent and MouseEvent. This make sense after all, mouse events should come from the Mouse class and same for the Keyboard. So this is how things keep together. It keeps things separate inside the Keyboard class, delegating the responsibility of events to the Event class for each parent. This means you can create a Keyboard/Mouse::Event and just pass that as a parameter instead of having to pass the whole parent class.
The downside to all of this is forward declarations don't work for the nested class. Now Mouse/Keyboard.h are small enough files and never change so I'm not really worried about build times with them. I do like not having to #include files in my headers though. I can reduce the chances of circular dependencies this way. Also, I decrease the number of #include chains, which means I only have to #include those headers that are needed in the .h file and different ones if needed in the .cpp file.
Aside from nested classes, there are other hindrances to putting all #include statements in cpp files. Take for instance std::vector or std::unique_ptr. In order for them to work, they need to know during compilation what and where the type is they are going to be working on. Other than that, storing concrete objects ( not pointers or references ) will also require you to #include their header files. This one is a nail biter for me lol. I COULD just store a raw pointer and handle all memory management manually, thus allowing me to keep most of my header includes in the cpp files, but I care more about runtime performance than build performance, so I'll keep my concrete objects on the stack thank you.
That's all, just a "little" rant about forward declarations and nested classes.
Take chili's Event classes in the Keyboard and Mouse classes. He can reuse the name Event because each is in the scope of the their respective parent classes making Event more like Keyboard::Event and Mouse::Event. This keeps from having to name those classes KeyboardEvent and MouseEvent. This make sense after all, mouse events should come from the Mouse class and same for the Keyboard. So this is how things keep together. It keeps things separate inside the Keyboard class, delegating the responsibility of events to the Event class for each parent. This means you can create a Keyboard/Mouse::Event and just pass that as a parameter instead of having to pass the whole parent class.
The downside to all of this is forward declarations don't work for the nested class. Now Mouse/Keyboard.h are small enough files and never change so I'm not really worried about build times with them. I do like not having to #include files in my headers though. I can reduce the chances of circular dependencies this way. Also, I decrease the number of #include chains, which means I only have to #include those headers that are needed in the .h file and different ones if needed in the .cpp file.
Aside from nested classes, there are other hindrances to putting all #include statements in cpp files. Take for instance std::vector or std::unique_ptr. In order for them to work, they need to know during compilation what and where the type is they are going to be working on. Other than that, storing concrete objects ( not pointers or references ) will also require you to #include their header files. This one is a nail biter for me lol. I COULD just store a raw pointer and handle all memory management manually, thus allowing me to keep most of my header includes in the cpp files, but I care more about runtime performance than build performance, so I'll keep my concrete objects on the stack thank you.
That's all, just a "little" rant about forward declarations and nested classes.