Say you have two assemblies (two dlls). The first contains a class called Base and the second contains a class called Derived which publicly inherits from Base.
When I use the tlb files to create C++ classes in Visual Studio 2005, I get Base and Derived classes, but one is not a subclass of the other. There doesn't seem to be any IS-A relationship. Is there a reason for this?
I'm assuming here, that the two assemblies communicate one with the other via COM, if that is indeed the case then you are correct, there is no IS-A relationship in COM in regard to CLASS inheritance, only in regard to Interface inheritance.
If you were to define an interface IBase and IDerived which derives from IBase, then you would be able to cast IDerived to IBase on the same object which implements both.
Related
If I have a class defined as :
// foo.h
class Foo
{
public:
virtual void GetFoo();
}
And I want a TForm to inherit from it, for example
class TFMainWindow : public TForm, public Foo
{
...
}
I get the error
[bcc32c Error] TFMainWindow.h(36): Delphi style classes have to be derived from Delphi style classes
How do I rsolve this issue?
TForm derives from TObject, which is a "Delphi-style class", ie it is implemented in Delphi pascal, not in C++. in Delphi, TObject is the root of all class object instances.
Delphi does not support multiple inheritance of classes, like C++ does. Only single inheritance. A Delphi class can have only 1 base class at most. But, it can implement multiple interfaces.
So, in C++Builder, when a C++ class has TObject as an ancestor, any other non-base ancestors MUST be interfaces only, which your Foo is not. An interface in this case is any class that has no data members, and only pure virtual methods and __property declarations are allowed.
If Foo::GetFoo() were a pure virtual method instead, then your code would work as expected, eg:
class Foo
{
public:
virtual void GetFoo() = 0;
};
class TFMainWindow : public TForm, public Foo
{
...
public:
void GetFoo();
...
};
This is simply a limitation of how C++ and Delphi interact with each other.
This is documented behavior:
C++ and Delphi Class Models: Inheritance and Interfaces
Unlike C++, the Delphi language does not support multiple inheritance. Any classes that you create that have RTL ancestors inherit this restriction. That is, you can not use multiple base classes for a Delphi style C++ class, even if the RTL class is not the immediate ancestor.
Using Interfaces Instead of Multiple Inheritance
For many of the situations where you would use multiple inheritance in C++, Delphi code makes use of interfaces instead. There is no C++ construct that maps directly to the Delphi concept of interface. An Delphi interface acts like a class with no implementation. That is, an interface is like a class where all the methods are pure virtual and there are no data members. While an Delphi class can have only a single parent class, it can support any number of interfaces. Delphi code can assign a class instance to variables of any of those interface types, just as it can assign the class instance to a variable of any ancestor class type. This allows polymorphic behavior for classes that share the same interface, even if they do not have a common ancestor.
In C++Builder, the compiler recognizes classes that have only pure virtual methods and no data members as corresponding to Delphi interfaces. Thus, when you create a Delphi style class, you are permitted to use multiple inheritance, but only if all of the base classes except the one that is a RTL or Delphi style class have no data members and only pure virtual methods.
Note: The interface classes do not need to be Delphi style classes; the only requirement is that they have no data members and only pure virtual methods.
Differences in object models between Delphi and C++ is also why C++ classes that are derived from TObject MUST be constructed in dynamic memory with new, even though C++ normally allows classes to be constructed in static/automatic memory without the use of new.
In composition, one class explicitly contains the other. However in Inheritance, the base class is implicitly contained in the derived class. Correct or not? I ask this because after several days of studying inheritance, it's only today that I got to read somewhere that an object of a derived class always contains an object of it's base class.
I mean, I thought that there would be only one object and just the functionality would be inherited but I didn't know that it would also contain an object of the base class within.
In Composition, one object contained another object. While in inheritance, your object is acquire properties of base class.
I mean, I thought that there would be only one object and just the
functionality would be inherited but I didn't know that it would also
contain an object of the base class within.
Yes you are right, there will be only one object and functionality is getting inherited. Even if your base class have member variables, there size will getting added to your object size.
You can directly call public and protected methods of base class. While in cointainership you are only able to access public methods.
That's should be:
In composition, one class explicitly contains an object of the other class. However in Inheritance, the base class is implicitly contained in the derived class.
In short:
Composition is about the relationship of class and object.
Inheritance is about the relationship of class and class.
And please remember "Prefer composition over inheritance".
Prefer composition over inheritance?
In general derived class contains all data members and shares the properties/methods of base class, but there is a difference between composition and inheritance.
By "composition" you mean that one object "has" some other object. In example: human has a liver. In class design it can be presented like below:
class Liver {};
class Human
{
public:
Human() {}
private:
Liver mLiver;
}
When talking about an inheritance, there are 2 options: public inheritance roughly says that one object "is" a kind of other object. In example: Human is a kind of living creature. It does not sound naturally to say that human "has" a living creature inside. Public inheritance is a way to go in such case:
class LivingCreature {};
class Human : public LivingCreature
{
public:
Human() {}
}
Other option is protected/private inheritance, which should be used to implement some object "in terms of" other object. Generally it can also be treated as kind of composition, but first approach is usually better.
Summarizing:
If you can say that one object "is" a kind of other, more general object: public inheritance is the best way to go,
If you can say that one object "has" other object: use composition.
Consider the code:
class Engine
{
//Some Code
};
class Vehicle
{
//Some Code
};
class Car:Vehicle
{
Engine engine;
//Some Code
};
In this case class Car inherits the class Vehicle. An object of the class Car doesn't contain an object Vehicle, rather it is an object of the class Vehicle (Inheritance). On the other hand it does contain an object of the class Engine(Composition).
The fact that you can access a parent's function with this comes from the fact that the Car object is a Vehicle not because it contains an Vehicle object.
In composition, one class explicitly contains the other. However in Inheritance, the base class is implicitly contained in the derived class. Correct or not?
It's entirely a matter of knowledge/perspective: if you're aware that inheritance means a base class instance will be embedded in the derived class then saying class Dervived : Base can be seen as explicitly requesting that, while if you're aware that defining a variable inside class X means it's a member variable that will be contained in instances of X, then that can be seen as explicit too.
I ask this because after several days of studying inheritance, it's only today that I got to read somewhere that an object of a derived class always contains an object of it's [sic] base class.
The distinction between actually containing a base class object vs. through some more unspecified/mysterious means being substitutable for a base class instance on occasion, isn't necessarily the most important thing when starting to learn about inheritance, so it's easy to imagine it isn't emphasised in all learning material.
I mean, I thought that there would be only one object and just the functionality would be inherited but I didn't know that it would also contain an object of the base class within.
At an implementation level, it's important that it actually contains a base class instance, so code compiled to handle base class objects can work equally well on derived class instances. The C++ Standard could have deemed it merely an embedded copy of base class content with identical binary layout while not an actual base class object, but then a huge amount of text in the Standard would have to be added to mention that the derived objects could be used in scenarios where a base class instance was acceptable. In other words, the distinction is somewhat arbitrary, but it's easier for everyone if it's both intuitive and lends itself naturally to simpler, more concise Standard wording.
Inheritance vs Composition:: Is my understanding correct?
Conceptual differences:
Inheritance:
In case of inheritance, derived class is sub-type of base class.
Meaning if you derive Dog from Animal, then Dog is Animal and
all* operations that can be performed on Animal can be performed on Dog.
Using private, protected and public inheritance, however, you can control who knows that Dog is Animal and who knows inner workings of Animal. In case of protected or private inheritance only Dog will know that it is Animal, but it won't be obvious from the outside.
Composition:
In case of composition one class is included into another.
a Car is not a Wheel. But it contains Wheel. So operations that work on Wheel will not work on a Car.
By declaring member variable of type Wheel as public, private or protected you can control who can access Car's Wheels.
I believe that is clear enough?
Implementation details:
In case of C++, members of base class are included into derived class. Also methods that existed in base class will be accessible in derived class - somewhere. Access specifiers private, public and protected AND inheritance type determine which methods are visible and where.
I thought that there would be only one object
It is one object.
In microsoft compiler and g++ objects are "merged" together, meaning that in case of:
struct Base{
int a;
};
strict Derived: public Base{
int b;
};
Derived internally will probably (would need to check C++ standard to be sure) have this layout.
strict Derived{
int a;
int c;
};
or
struct Derived{
Base _;
int c;
};
In case of multiple inheritance and diamond inheritance things will get more complicated and base class can be included multiple times.
I have multiple QObject subclasses which should act as interface classes and be implemented by (inherited by) some other classes. For example let class A : virtual public QObject and class B : virtual public QObject be interface classes. I need a QDialog object to implement their behavior like: class X: public QDialog, A, B.
Unfortunately I did not read documentation carefully at design time and now I realized two facts:
implementing slots as pure virtual member functions is not possible because moc-generated code will need to call them.
Multiple inheritance is not supported for QObject-derived classes. That's not a diamond thing. It's because moc-generated code can't static_cast a virtual QObject object to a A* via virtual base. (That's what compiler says!)
What is best possible alternative design to which affects code as less as possible? I can think of macro hacks. Maybe a macro in base class (like Q_OBJECT) to copy all members, signals, slots of base to derived class?
Note That's really bad that QObjects can't be inherited multiple times. Isn't?
If you really need to expose QObject member functions through your A and B classes create an abstract base class (i.e. a class with only pure virtual member functions), say AbstractQObject, and re-declare there the QObject member functions you need to expose.
Have A and B derive virtually from AbstractQObject and X from QDialog, A and B.
This should solve the problem you described, but I suspect you would be better off redesigning your code.
I found those two terms in the book of Meyers, but what is the difference?
Interface inheritance is public inheritance, while implementation inheritance is private inheritance.
If class B publicly inherits from A, B is an A: it inherits the whole interface of A, and a (reference/pointer to) a B object can be automatically be upcasted to A, and used wherever an object of A is expected. However, if B privately inherits from A, B is-implemented-in-terms-of A: only the implementation of A is inherited, not its interface. Thus (references/pointers to) B objects can not be used in places where A objects are expected.
Update
To reflect on #Michal's comment, here are some links (based largely on googling "c++ implementation inheritance") to demonstrate the common usage of these terms in the context of C++:
C++ Design/Coding tips - Part 7
Interfaces
Uses and Abuses of Inheritance, Part 1
Implementation (or class) inheritance is when you separate a common part of implementation in the base class.
Interface inheritance is when you use virtual methods. It is intended to separate interface from implementation and minimize dependencies between program elements.
The major difference is interface is public inheritance and implementation is private inheritance.
The data members and method of the public and protected section will be inherited from base class to derived class in their respective access specifier in public inheritance.At the same time the object of derived class can access the data members of base class as the normal method.
The data members and methods of public and protected section will be inherited from base class to derived class in private access specifier
Here's the difference between the two types of inheritance according to "Taligent's Guide to Designing Programs".
Inheritance
There are two forms of inheritance in C++: type inheritance and implementation inheritance. In both forms of inheritance, a derived class can share or override behavior inherited from a base class. However, use type inheritance only when it is necessary for a derived class to inherit type information as well. The primary reason to inherit type information is to allow for polymorphism.
Express type inheritance by deriving a class from a public base class; express implementation inheritance by deriving a class from a private or protected base class.
More at:
https://root.cern/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_23.html
I have never seen a class used as virtual and nonvirtual base (i.e. if some class is intended to be an ancestor then we usually know in advance about type of inheritance - virtual or nonvirtual).
So I suppose that there is an error-prone freedom in c++ to specialize "virtual" inheritance in base class list. It should be better to specify as "virtual" the base class itself
Or maybe I'm wrong?
If no, can anybody describe some technics to prevent accidental nonvirtual inheritance for such a "virtual" class?
Or there are some perspectives in upcoming c++ standards?
(Sorry if duplicate)
Some examples
1) ReferenceCounted class as base for all classes that some reference-count-based smartpointer can point to. We need to prevent duplicates of this base instances (and reference counters). There are no reasons to use this class as nonvirtual base, except of optimization.
2) A hierarchy of interfaces and corresponding hierarchy of implementations
(interfaces hierarchy must be "virtual" in this case)
// interfaces:
struct BaseIface{
void virtual func()=0;
};
struct DerivedIface: public virtual BaseIface{
void some_another_func()=0;
}
// implementations
class BaseImpl: public virtual BaseIface{
void virtual func(){....};
}
class DerivedImpl: public BaseImpl, public virtual DerivedIface{
void some_another_func(){...};
}
I suspect that in many cases nonvirtual inheritance is not a conceptual need, it used only to reduce virtual inheritance overhead (and sometimes for an ability to static_cast<> to drived :)
Note, that Java used ONLY virtual (in terms of c++) inheritance for interfaces, and I don't know any complains that this language lacks "nonvirtual" (it is esentially less expressive language than c++ but this "feature" is not it's main fault :).
There's not really much way you could do this in the base class (nor would you really want to). It's perfectly reasonable to use a base class for both virtual and non-virtual inheritance.
What you'd really like would be to specify the virtual inheritance in the most derived class, where currently has to be specified in the intermediate classes. Unfortunately, I don't see much way around that -- even though virtual inheritance becomes necessary (primarily) when a class derives from two (or more) other classes that each have a common base, the virtual inheritance really governs how those two other classes are compiled, so if you (only) specified it in the most derived class, you'd end up with something almost like export, where you might need to go back and re-compile those intermediate classes based on the most derived class specifying virtual inheritance (and have some way to store the intermediate classes compiled both ways since it might be used either or both ways).