Normally most of the MFC (window based classes) are derived from CObject.
What does CObject do?
Why some MFC classes are not required to be derived from CObject?
According to MSDN CObject mainly provides these features:
Serialization support
Run-time class information
Object diagnostic output
Compatibility with collection classes
So when none of this is needed, there is no need to derive from CObject.
There a bit of overhead (DECLARE/IMPLEMENENT_SERIAL/DYNAMIC macros) involved when deriving from CObject, too, so there may be simpler ways of doing things than by deriving from CObject.
The MFC documentation covers this pretty well. The documentation for CObject describes what it does (serialization support, runtime class information etc).
The Hierarchy Chart is a good overview, and shows which classes aren't derived from CObject.
You can conclude that the classes that don't derive from CObject are the ones that don't need the services it provides. The reasons are various: for example a class like CFileTime is a simple data type.
Related
Is there a real-world example where non-virtual multiple inheritance is being used? I'd like to have one mostly for didactic reasons. Slapping around classes named A, B, C, and D, where B and C inherit from A and D inherits from B and C is perfectly fine for explaining the question "Does/Should a D object have one or two A sub-objects?", but bears no weight about why we even have both options. Many examples care about why we do want virtual inheritance, but why would we not want virtual inheritance?
I know what virtual base classes are and how to express that stuff in code. I know about diamond inheritance and examples of multiple inheritance with a virtual base class are abundant.
The best I could find is vehicles. The base class is Vehicle which is inherited by Car and Boat. Among other things, a Vehicle has occupants() and a max_speed(). So an Amphibian that inherits from both Car and Boat inherits different max_speed() on land and water – and that makes sense –, but also different occupants() – and that does not make sense. So the Vehicle sub-objects aren't really independent; that is another problem which might be interesting to solve, but this is not the question.
Is there an example, that makes sense as a real-world model, where the two sub-objects are really independent?
You're thinking like an OOP programmer, trying to design abstract models of things. C++ multiple inheritance, like many things in C++, is a tool that has a particular effect. Whether it maps onto some OOP model is irrelevant next to the utility of the tool itself. To put it another way, you don't need a "real-world model" to justify non-virtual inheritance; you just need a real-world use case.
Because a derived class inherits the members of a base class, inheritance often is used in C++ as a means of collecting a set of common functionality together, sometimes with minimal interaction from the derived class, and injecting this functionality directly into the derived class.
The Curiously Recurring Template Pattern and other mixin-like constructs are mechanisms for doing this. The idea is that you have a base class that is a template, and its template parameter is the derived class that uses it. This allows the base class to have some access to the derived class itself without virtual functions.
The simplest example I can think of in C++ is enable_shared_from_this, which allows an object whose lifetime is currently managed by a shared_ptr to actually retrieve a shared_ptr to that object just from a pointer/reference to that object. That uses CRTP to add the various members and interfaces needed to make shared_from_this possible to the derived class. And since the inheritance is public, it also allows shared_ptr's various functions that "enable shared_from_this" to to detect that a particular type has the shared_from_this stuff in it and to properly initialize it.
enable_shared_from_this doesn't need virtual inheritance, and indeed would probably not work very well with it.
Now imagine that I have some other CRTP class that injects some other functionality into an object. This functionality has nothing to do with shared_ptr, but it uses CRTP and inheritance.
Well, if I now write some type that wants to inherit from both enable_shared_from_this and this other functionality, well, that works just fine. There is no need for virtual inheritance, and in fact doing so would only make composition that much harder.
Virtual inheritance is not free. It fundamentally changes a bunch of things about how a type relates to its base classes. If you inherit from such a type, your constructors have to initialize any virtual base classes directly. The layout of such a type is very odd and is highly unlikely to be standardized. And various other things. C++ tries not to make programmers pay for functionality they don't use, so if you don't need the special properties of virtual inheritance, you shouldn't be using it.
Its the same reason C++ has non-virtual methods -- because the implementation is simpler and more efficient if you use non-virtual inheritance, so you need to explicitly ask for virtual inheritance if you want it. Since you don't need it if your classes never use multiple inheritance, that is the default.
When and Why to use abstract classes/methods?
When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. ( COM was designed around interfaces.) Use an abstract class to define a common base class for a family of types. Use an abstract class to provide default behavior. Subclass only a base class in a hierarchy to which the class logically belongs.
I did not understand the explanation in the above quote. Please explain why should an abstract class be used for creating a class library?
You should read articles of such kind very carefully. As I Understood, the main part of article is dedicated to c# language. In terms of such language there is big difference between interfaces and abstract classes. For example, interfaces in terms of c# language is just set of "pure" virtual methods (they cannot have definition within interface, only classes can implement it). Interfaces cannot have constructors. Abstract classes can have constructors. Moreover, c# does not support multiple inheritance ( as opposite to c++ language). In such way, c# interfaces and abstract classes look very different than c++'s one
In Qt there is a class QAbstractTableModel, its an abstract class. Why Qt designers provide an abstract class, and doesn't provide an actual class that can be used for modelling a table. Why the designer made me to subclass the class to use it?
That's because that class is not used for modelling a table, it's an interface that all classes that model a table must adhere to. Qt has a few concrete models that you can reuse, simply look at the "Inherited by" list in the documentation of the base QAbstractItemModel class. Some of these derived classes are concrete, namely those whose names don't start with QAbstract :)
If you want a generic model, you can use a QStandardItemModel.
You'll need to read up about interfaces in C++. An interface implemented using abstract virtual methods is a very common idiom. See e.g. here. In C++11 you can have interfaces that don't use the virtual method idiom, though.
If you ask "why doesn't Qt provide any general-purpose concrete classes that implement that interface", the answer is: because it's an impossible job. Everyone's data source has different implementation details, and Qt can't possibly divine everyone's approach and provide a universal bridge.
The QAbstractTableModel exists to let you create an adapter between your own data model and Qt's data model.
There is universal model implementation such as QStandardItemModel, so you can use this for table, tree or list views as you need.
I'm making a game GUI API where each widget inherits from the Widget class. I was thinking, when others make there own widgets, they might not be fully satisfied with the base class. They might want to add getTheme() for example. Would it be a good idea to make all my widgets virtually inherit from Widget then so that this is possible?
Thanks
Just because the user would add their own methods to a child class doesn't mean you need to use virtual inheritance. You would use it if, in your library, you have a single base class with multiple children, and people could inherit from multiple child classes at once (for example mixin rather than substitution).
To resolve a diamond-shaped inheritance problem. (B and C both inherit from A. What happens to A's attributes in D that itself inherits from B and C?)
A client of your library could see a RedWidget and a FlyingWidget, and might want to combine them into a RedFlyingWidget.
User would have to specify one of the base classes to be virtual when inheriting. But that is not responsibility of a library maker.
OOP flows better with single-implementation inheritance, so that's what I'd use throughout a library.
There are also "upside-down inheritance" trees, as described by Alexandrescu's excellent "Modern C++ Design." They allow clients to pull in more functionality in a form of mix-ins that are called policies.
Programming with policies allows for greater ability to combine functionality, at the expense of syntactical cleanliness. Think STL implementation, for example.
When is virtual inheritance a good idea?
That's a design question.
For your Widgets, I would say Yes, multi-derived classes should have the option to be just 1 Widget.
Whenever there is a possibility that the users of your library are going to use several classes from your library as a base class (ie derive from them), you have to use virtual inheritance. In other words, it is a good idea to use it in your case.
I had faced the problem. In my C++ hierarchy tree I have two branches for entities of difference nature, but same behavior - same interface. I created such hierarchy trees (first in image below).
And now I want to work with Item or Base classes independetly of their nature (first or second). Then I create one abstract branch for this use. My mind build (second in image below).
But it not working. Working scheme seems (third in image below).
It's bad logic, I think...
Do anybody have some ideas about such hierarchy inheritance? How make it more logical? More simple for understanding?
Image
Sorry for my english - russian internet didn't help:)
Update:
You ask me to be more explicit, and I will be.
In my project (plugins for Adobe Framemaker) I need to work with dialogs and GUI controls. In some places I working with WinAPI controls, and some other places with FDK (internal Framemaker) controls, but I want to work throw same interface.
I can't use one base class and inherite others from it, because all needed controls - is a hierarchy tree (not one class).
So I have one hierarchy tree for WinAPI controls, one for FDK and one abstract tree to use anyone control.
For example, there is an Edit control (WinEdit and FdkEdit realization), a Button control (WinButton and FdkButton realization) and base entity - Control (WinControl and FdkControl realization).
For now I can link my classes in realization trees (Win and Fdk) with inheritence between each of them (WinControl is base class for WinButton and WinEdit; FdkControl is base class for FdkButton and FdkEdit). And I can link to abstract classes (Control is base class for WinControl and FdkControl; Edit is base class for WinEdit and FdkEdit; Button is base class for WinButton and FdkButton). But I can't link my abstract tree - compiler swears.
In fact I have two hierarchy trees, that I want to inherite from another one.
Update:
I have done this quest! :)
I used the virtual inheritence and get such scheme (http://img12.imageshack.us/img12/7782/99614779.png). Abstract tree has only absolute abstract methods. All inheritence in abstract tree are virtual. Link from realization tree to abstract are virtual. On image shown only one realization tree for simplicity.
Thanks for help!
C++ supports multiple inheritance, so you can have the union of (2) and (3), making sure that AbstractBase is always declared as a virtual base class.
Without knowing the real meaning and purpose of the various classes, it's difficult to offer any better advice.
It's not clear from the description if this would work for you but typically classes with a common interface would define the interface in AbstractBase and then have concrete instances inherit directly from that (FirstItem, SecondItem).
Why the extra indirection(s) in your examples? What's expected to be in AbstractItem, FirstBase and SecondBase?
For using different implementations of one interface, on could use:
the Bridge Design Pattern
You might couple this with a Factory Design Pattern so as to construct your two implementations differently.
However, it may look too simple for your classes architecture.
But as the comments under your answer say: it is difficult to imagine the job/role of your classes with such names. You should be more explicit, so as we can think of a precise design.