My understanding is that abstract classes must have one or more pure virtual methods.
Can this class be considered abstract?
class B {
protected:
B() { }
public:
virtual ~B() { }
};
Finally, is the term abstract class defined in any of the recent C++ standards?
No, such a class cannot be considered abstract because (as mentioned in the comments, excerpt from the working draft):
A class is abstract if it has at least one pure virtual function.
Unfortunately, there are cases when one cannot add a pure virtual method to a class to turn it in an abstract one and still he doesn't want users to be able to instantiate that class.
For the sake of curiosity, I'm adding this answer to mention an often unknown technique to work around the issue.
Actually, you can easily turn such a class in an abstract one, even if you don't have any virtual method to be added to it.
The basic idea is to exploit the destructor declaration to do that.
A minimal, (not) working example follows:
struct B { virtual ~B() = 0; };
// keep in mind the ODR
B::~B() { }
int main() { B b{}; }
The code above won't compile with the error:
cannot declare variable 'b' to be of abstract type 'B'
Please, note that the definition of the destructor should be placed in a .cpp file, so as not to violate the ODR.
To be honest, I haven't found any case in which this technique can be used till now. Anyway, it's worth mentioning it for future readers.
abstract classes must have one or more pure virtual methods.
Exactly, and you class don't have it.
In accordance with this, a abstract class is a type which cannot be instantiated, but can be used as a base class (note: not "by"). In C++ this can be achieved with the usage of pure virtual method.
A pure virtual method is a virtual function whose declarator has the following syntax:
class B {
virtual void foo() = 0;
}
Note: the syntax = 0 which indicates a pure virtual method. That simply means you don't have to specify an implementation for that method, and it cannot be possible to create any instance of that class (that is, a abstract class).
In conclusion your class B is not an abstract class.
Finally, is the term abstract class defined in any of the recent C++ standards?
The abstract class is a definition itself, and it's define as I've just mentioned before.
If you mean a specific defined syntax as, for example in Java (abstract class ...), then the answer is no. Again an abstract class in C++ is defined just with a class which has a pure virtual method.
No, class B can not be considered as abstract.
class A {
public:
virtual void method() = 0;
virtual ~A() = 0;
}
A is pure virtual, you cannot create object of A. You must create children class B which implements method after A.
Related
This may seem like a simple question, but I can't find the answer anywhere else.
Suppose I have the following:
class Abstract {
public:
virtual void foo() = 0;
virtual void bar();
}
class Derived : Abstract {
public:
virtual void foo();
}
Is it ok that class Derived does not implement the bar() function?
What if not ALL of my derived classes need the bar() function, but some do.
Do all of the virtual functions of an abstract base class need to be implemented in the derived classes, or just the ones that are pure virtual?
Thanks
Derived classes do not have to implement all virtual functions themselves. They only need to implement the pure ones.1 That means the Derived class in the question is correct. It inherits the bar implementation from its ancestor class, Abstract. (This assumes that Abstract::bar is implemented somewhere. The code in the question declares the method, but doesn't define it. You can define it inline as Trenki's answer shows, or you can define it separately.)
1 And even then, only if the derived class is going to be instantiated. If a derived class is not instantiated directly, but only exists as a base class of more derived classes, then it's those classes that are responsible for having all their pure virtual methods implemented. The "middle" class in the hierarchy is allowed to leave some pure virtual methods unimplemented, just like the base class. If the "middle" class does implement a pure virtual method, then its descendants will inherit that implementation, so they don't have to re-implement it themselves.
Only the pure virtual methods have to be implemented in derived classes, but you still need a definition (and not just a declaration) of the other virtual methods. If you don't supply one, the linker might very well complain.
So, just putting {} after your optional virtual method gives you an empty default implementation:
class Abstract {
public:
virtual void foo() = 0; // pure virtual must be overridden
virtual void bar() {} // virtual with empty default implementation
};
class Derived : Abstract {
public:
virtual void foo();
};
A more involved default implementation would go into a separate source file though.
The ISO C++ Standard specifies that all virtual methods of a class that are not pure-virtual must be defined.
Simply put the rule is:
If your derived class overiddes the Base class virtual method then it should provide a definition as well, If not then the Base class should provide the definition of that method.
As per the above rule in your code example, virtual void bar(); needs a definition in the Base class.
Reference:
C++03 Standard: 10.3 Virtual functions [class.virtual]
A virtual function declared in a class shall be defined, or declared pure (10.4) in that class, or both; but no diagnostic is required (3.2).
So either you should make the function pure virtual or provide a definition for it.
The gcc faq doccuments it as well:
The ISO C++ Standard specifies that all virtual methods of a class that are not pure-virtual must be defined, but does not require any diagnostic for violations of this rule [class.virtual]/8. Based on this assumption, GCC will only emit the implicitly defined constructors, the assignment operator, the destructor and the virtual table of a class in the translation unit that defines its first such non-inline method.
Therefore, if you fail to define this particular method, the linker may complain about the lack of definitions for apparently unrelated symbols. Unfortunately, in order to improve this error message, it might be necessary to change the linker, and this can't always be done.
The solution is to ensure that all virtual methods that are not pure are defined. Note that a destructor must be defined even if it is declared pure-virtual [class.dtor]/7.
Yes, that's fine ... you only need to implement any pure virtual functions in order to instantiate a class derived from an abstract base class.
Yes, Its correct that a Derived class has to OVERRIDE the function which is Pure Virtual in the Parent Class. Parent class having a Pure Virtual Function is called Abstract Class only because it's Child class must give their own body of the Pure Virtual Function.
For the Normal Virtual Functions:-
Its not necessary to override them further, as some child class may have that function, some may not have.
Main purpose of Virtual Function mechanism is Run Time Polymorphism, whether main purpose of Pure Virtual Function(Abstract Class) is to make it mandatory to have the same name Function with own's body.
As it is explained in The C++ programming language:
virtual void push(char c) = 0;
virtual void pop() = 0;
The word virtual means 'may be redefined later in a class derived from this one'
The =0 syntax says that some class derived from Stack must define the function.
So why =0 symbol is needed? Does it means that a derived class must define this function, and that's to say when there is no =0, some derived classes are not forced to define this method?
I'm confusing about this, need some help.
Your thoughts were right.
So why =0 symbol is needed? Does it means that a child class must
define this function, and that's to say when there is no =0, some
child classes are not forced to define this method?
Basically you can:
Make a method non-virtual
This doesn't allow any class deriving from the class that implements the method (through either public or protected) to change the method's behavior.
Make a method virtual
This allows (but doesn't enforce) any class deriving from the class that implements the method (through either public or protected) to change the behavior of the method in the base class. You don't even have to call the original base class method anymore so you can make severe changes if needed.
Make a method pure virtual ( virtual = 0 )
This enforces that any class deriving from the class that implements the method (through either public or protected) to implement some kind of behavior/body for this method. If the deriving class does not provide an implementation then this class will instantly become abstract itself. This allows to omit the behavior/body of the method in the base class and because of this it is not allowed to directly instantiate a class that has one or more pure virtual methods (abstract class).
So why =0 symbol is needed?
Consider the following:
struct foo
{
virtual void some() const { cout << "foo" << endl; }
};
struct bar : public foo
{
virtual void some() const { cout << "bar << endl; }
};
struct baz : public foo
{
}
Suppose you have a pointer foo *p pointing to some object, and you call p->some().
If p points to a bar object, it will print "bar".
If p points to a baz object, it will print "foo".
In some cases, this might not be what you want. You might want to specify that any derived class needs to override it. The =0 does that.
The purpose of an abstract class (those classes have pure virtual method, =0) is to provide an appropriate base class from which other classes can inherit. Abstract classes cannot be used to instantiate objects and serves only as an interface.
Thus, if a subclass of an abstract class needs to be instantiated, it has to implement each of the virtual functions, which means that it supports the interface declared by the abstract class.
That is the base concept for interface.
In short, it a way to be sure a derivative class will implement those methods from the base class.
So why =0 symbol is needed?
Virtual function with sequence = 0 is known as pure virtual function, (the sequence = 0 is known as pure-specifier), it makes the class an abstract class, which can't be instantiated. For the derived classes, if they want to make it possible to be instantiated, they have to implement the pure virtual function.
No objects of an abstract class can be created. Abstract types cannot be used as parameter types, as function return types, or as the type of an explicit conversion. Pointers and references to an abstract class can be declared.
For example,
class Stack {
virtual void push(char c) = 0;
};
...
Stack s; // Fail, Stack is an abstract class
and if
class Stack {
virtual void push(char c);
};
...
Stack s; // Fine, if you won't call `push()` on it.
First consider what is the reason to use virtual methods.
1.Interface(polymorphism).
Interface in C++ is a pure virtual class, which means, that all of its methods are pure virtual (like these two you've mentioned above), it has an virtual destructor and has no constructor (it's obvious, because we can't create its instances). It also shouldn't have any data.
Let's define an interface (pure abstract class in C++):
class Interface
{
public:
virtual ~Interface(){}
virtual void somePublicMethod() = 0;
};
And define the class, which is an implementation of interface:
class Implementation : public Interface
{
public:
~Implementation() override {}
void somePublicMethod() override {}
};
If you define another pure virtual method in interface:
virtual void anotherPublicMethod() = 0;
And you don't override it in implementation you will receive compilation error, when you will declare object of Implementation type, because real Implementation object must have definitions (bodies) for all derived methods.
Yo can also define default behavior of some interface's method:
void Interface::somePublicMethod()
{
//define default behavior here
}
And call it in derived class:
void Implementation::somePublicMethod()
{
Interface::somePublicMethod();
}
How interface is used in polymorphism you will read in other topics.
2."Ordinary" Inheritance.
In "ordinary" inheritance you should use virtual methods instead of pure virtual ones, because you want to have instances of both Base class and Derived class(es). Virtual methods only indicates, that they could be overridden in derived class(es).
Conclusion
In general, if you want to have an instance of any class, this class must have all methods defined (so the must have bodies and it's obvious that they mustn't be pure virtual).
I made a test code as following:
#include <iostream>
using namespace std;
#ifndef interface
#define interface struct
#endif
interface Base
{
virtual void funcBase() = 0;
};
interface Derived1 : public Base
{
virtual void funcDerived1() = 0;
};
interface Derived2 : public Base
{
virtual void funcDerived2() = 0;
};
interface DDerived : public Derived1, public Derived2
{
virtual void funcDDerived() = 0;
};
class Implementation : public DDerived
{
public:
void funcBase() { cout << "base" << endl; }
void funcDerived1() { cout << "derived1" << endl; }
void funcDerived2() { cout << "derived2" << endl; }
void funcDDerived() { cout << "dderived" << endl; }
};
int main()
{
DDerived *pObject = new Implementation;
pObject->funcBase();
return 0;
}
The reason I wrote this code is to test if the function funcBase() can be called in an instance of DDerived or not. My C++ complier (Visual Studio 2010) gave me a compile error message when I tried to compile this code. In my opinion, there is no problem in this code because it is certain that the function funcBase() will be implemented (thus overriden) in some derived class of the interface DDerived, because it is pure virtual. In other words, any pointer variable of type Implementation * should be associated with an instance of a class deriving Implentation and overriding the function funcBase().
My question is, why the compiler give me such an error message? Why the C++ syntax is defined like that; i.e., to treat this case as an error? How can I make the code runs? I want to allow multiple inheritance of interfaces. Of course, if I use "virtual public" or re-declare the function funcBase() in Implementation like
interface DDerived : public Derived1, public Derived2
{
virtual void funcBase() = 0;
virtual void funcDDerived() = 0;
};
then everything runs with no problem.
But I don't want to do that and looking for more convenient method, because virtual inheritance may degrade the performance, and re-declaration is so tedious to do if inheritance relations of classes are very complex. Is there any methods to enable multiple inheritance of interfaces in C++ other than using virtual inheritance?
As you've defined it, your object structure looks like this:
The important point here is that each instance of Implementation contains two entirely separate instances of Base. You're providing an override of Base::funcBase, but it doesn't know whether you're trying to override funcBase for the Base you inherited through Derived1, or the Base you inherited through Derived2.
Yes, the clean way to deal with this is virtual inheritance. This will change your structure so there's only one instance of Base:
This is almost undoubtedly what you really want. Yes, it got a reputation for performance problems in the days of primitive compilers and 25 MHz 486's and such. With a modern compiler and processor, you're unlikely to encounter a problem.
Another possibility would be some sort of template-based alternative, but that tends to pervade the rest of your code -- i.e., instead of passing a Base *, you write a template that will work with anything that provides functions A, B, and C, then pass (the equivalent of) Implementation as a template parameter.
The C++ language is designed in such a way that in your first approach without virtual inheritance there will be two parent copies of the method and it can't figure out which one to call.
Virtual inheritance is the C++ solution to inheriting the same function from multiple bases, so I would suggest just using that approach.
Alternately have you considered just not inheriting the same function from multiple bases? Do you really have a derived class that you need to be able to treat as Derived1 or Derived2 OR Base depending on the context?
In this case elaborating on a concrete problem rather than a contrived example may help provide a better design.
DDerived *pObject = new Implementation;
pObject->funcBase();
This creates a pointer of type DDerived to a Implementation. When you are using DDerived you really just have a pointer to an interface.
DDerived does not know about the implementation of funcBase because of the ambiguity of having funcBase being defined in both Derived1 and Derived2.
This has created a inheritance diamond which is what is really causing the problem.
http://en.wikipedia.org/wiki/Diamond_problem
I also had to check on the interface "keyword" you have in there
it's an ms-specific extension that's recognised by visual studio
I think C++ Standard 10.1.4 - 10.1.5 can help you to understand the problem in your code.
class L { public: int next; /∗ ... ∗/ };
class A : public L { /∗...∗/ };
class B : public L { /∗...∗/ };
class C : public A, public B { void f(); /∗ ... ∗/ };
10.1.4 A base class specifier that does not contain the keyword virtual,
specifies a non-virtual base class. A base class specifier that
contains the keyword virtual, specifies a virtual base class. For each
distinct occurrence of a non-virtual base class in the class lattice
of the most derived class, the most derived object (1.8) shall contain
a corresponding distinct base class subobject of that type. For each
distinct base class that is specified virtual, the most derived object
shall contain a single base class subobject of that type. [ Example:
for an object of class type C, each distinct occurrence of a
(non-virtual) base class L in the class lattice of C corresponds
one-to-one with a distinct L subobject within the object of type C.
Given the class C defined above, an object of class C will have two
subobjects of class L as shown below.
10.1.5 In such lattices, explicit qualification can be used to specify which
subobject is meant. The body of function C::f could refer to the
member next of each L subobject: void C::f() { A::next = B::next; } //
well-formed. Without the A:: or B:: qualifiers, the definition of C::f
above would be ill-formed because of ambiguity
So just add qualifiers when calling pObject->funcBase() or solve ambiguity in another way.
pObject->Derived1::funcBase();
Updated: Also very helpful reading will be 10.3 Virtual Functions of Standard.
Have a nice weekend :)
I am working on an exercise which asks me to take a base class Rodent and make it a pure abstract class. My understanding of a pure abstract class is that it acts as an interface and only contains pure virtual functions. Although this is an easy exercise I have a problem with the solution provided by the book:
class Rodent
{
public:
virtual ~Rodent() {cout << "Destroy rodent" << endl;}
virtual void run() = 0;
virtual void squeak() = 0;
};
As you can see the author has added a dummy definition for the destructor. Does the adding of this definition not mean that this is an abstract class and not a 'pure' abstract class?
An Abstract class must contain atleast one pure virtual function.
Your class already has two pure virtual functions run() and squeak(), So your class is Abstract because of these two pure virtual functions.
You cannot create any objects of this class.
EDIT:
A pure abstract class, is a class that exclusively has pure virtual functions (and no data).
Since your destructor is not pure virtual your class is not Pure Abstract Class.
A destructor is required for every class by the rules of C++. If you don't provide one, the compiler will generate one for you.
In my opinion this is still a pure abstract class, because the destructor is an exception to the rule.
The virtual keyword means something a bit different for destructors. When a base class's dtors are virtual, it means all dtors in the inheritance hierarchy are called. You can't really override it as such.
Usually you'd expect it to be empty:
class Rodent {
public:
virtual ~Rodent() {}
virtual void run() = 0;
virtual void squeak() = 0;
};
I see very little difference. It is possible that because the empty body is a no-op the compiler can ignore it through some language lawyer statute.
I don't think you'd confuse anyone by calling yours pure virtual.
As far as I understand, the C++ standard does not specify a pure abstract class. The C++0x (n3290) however specifies abstract class.
10.4/2 A class is abstract if it has at least one pure virtual
function.
The pure abstract class is a conventional term and describes an abstract class that;
does not have of data members
does not have of any non-pure virtual functions
does not have of any concrete functions
specified by user.
So, according to this convention, the class Rodent is not a pure abstract class.
Consider implementing your interface like so
class Rodent {
public:
virtual ~Rodent() = 0;
virtual void run() = 0;
virtual void squeak() = 0;
};
inline Rodent::~Rodent() {}
Specifying your destructor as pure virtual and inlining the implementation avoids the following warning in MSVC2010 when exporting subclasses:
warning C4275: non dll-interface class 'A' used as base for dll-interface class 'B'
Yes, it is not a pure class anymore. A pure, abstract class has no functionality in it, it just provides a framework. cout is functionality.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the difference between a concrete class and an abstract class?
I was coding something in Visual C++ 2008 doing an exercise in a book I am reading when I held my cursor over one of the classes and it told me it was an abstract class. Now I know it is an abstract class as that is what this exercise is about but I was curious as to what lets the Intelisense thing know that it is an abstract class.
I did a little homework and found that it may have been the fact that I have two virtual functions in this class and one of them is a pure virtual.
Is the pure virtual a dead giveaway or are there other things that would tell you you are dealing with or looking at an abstract class?
Is the pure virtual a dead giveaway
In C++, yes. Since it has no abstract keyword or equivalent, the common idiom to make a class abstract is to declare a pure virtual function in it (which prevents instantiation).*
For this same reason, in C++ there is not much difference between an interface and an abstract class - a C++ interface is simply a class containing only pure virtual functions.
*Update: Another way to prevent instantiation of a class is to declare its constructor(s) protected or private. The latter means it can't be subclassed either, but the former doesn't prevent subclassing, so in theory a protected constructor could also be a sign of an abstract class a way to force subclassing. However, I have never seen this in practice. I believe this is because an abstract class is designed to be extended, which in practice almost always means it has virtual functions. And the reason why we want it to be abstract is because some part of its implementation is not yet known, hence it is to be defined in its subclass(es). Which is exactly what a pure virtual function is meant for.
The only thing that makes a class abstract is if it has one or more unimplemented pure virtual functions, possibly derived ones.
struct A { // abstract
virtual void f() = 0;
};
struct B : public A { // abstract
};
struct C : public B { // not abstract
void f() {}
};
Note that A should also have a (probably not pure) virtual destructor.
It is also possible to implement pure virtual functions, but this is pretty rare:
struct D {
virtual void f() = 0;
};
The function has to be defined outside the class:
void D :: f() {}
but the class remains abstract.
I wouldn't say I'm an expert in C++ but I would say you've nailed it. The presence of a pure virtual method means that the class cannot be instantiated and is therefore abstract. If all of your methods are pure virtual (i.e. there is no implementation) it would be an interface and in this case you only need the header file.