Reece Dunn wrote:
David Abrahams wrote:
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
The heirarchy above is for a UI object, where a UI object has moving/positioning and event handling integral to it. Consider:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base? Here, I was using the namespace as part of the name to denote the role that the class plays, not that it is a monolithic uberclass.
A layout manager that can be moved?? Maybe you have something else in mind, but I understand a layout manager to be a supplier of logic with no graphical representation. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com