By Aaron Fischer

2008-11-25 16:48:47 8 Comments

How do I setup a class that represents an interface? Is this just an abstract base class?


@Joel Coehoorn 2008-11-25 17:01:06

The whole reason you have a special Interface type-category in addition to abstract base classes in C#/Java is because C#/Java do not support multiple inheritance.

C++ supports multiple inheritance, and so a special type isn't needed. An abstract base class with no non-abstract (pure virtual) methods is functionally equivalent to a C#/Java interface.

@Ha11owed 2012-08-01 06:05:30

It would still be nice to be able to create interfaces, to save us from typing so much (virtual , =0, virtual destructor). Also multiple inheritance seems like a really bad idea to me and I've never seen it used in practice, but interfaces are needed all the time. To bad the C++ comity won't introduce interfaces just because I want them.

@Miles Rout 2013-01-01 06:51:44

Ha11owed: It has interfaces. They're called classes with pure virtual methods and no method implementations.

@doc 2014-10-15 16:50:08

@Ha11owed There are some quirks in Java caused by lack of multiple inheritance. Take a look at java.lang.Thread class and java.lang.Runnable interface, which exists just because you can not extend Thread along with another base. From documentation it may seem that it's provided for your choice, but I was once forced to use Runnable because of lack of multiple inheritance.

@Ha11owed 2014-11-28 15:04:28

@MilesRout: I know, but still, why force me write so much boilerplate code? Also it would be clear that you are looking at an interface without having to scan all methods and check that they are all pure virtual.

@Ha11owed 2014-11-28 15:05:53

@doc: java.lang.Thread has methods and constants that you probably don't want to have in your object. What should the compiler do if you extend from Thread, and another class with the public method checkAccess()? Would you really prefer to use strongly named base pointers like in C++? This seems like bad design, you usually need composition where you think that you need multiple inheritance.

@doc 2014-11-28 15:21:17

@Ha11owed it was long time ago so I don't remember details, but it had methods and contants that I wanted to have in my class and more importantly I wanted my derived class object to be a Thread instance. Multiple inheritance can be bad design as well as composition. It all depends on case.

@Joel Coehoorn 2014-11-30 03:49:05

@Ha11owed +1 for "you usually need composition where you think that you need multiple inheritance"

@Don Larynx 2015-03-24 04:19:04

There is no abstract keyword in C++.

@Dave 2015-12-16 05:53:48

"The whole reason you have a special Interface type-category in addition to abstract base classes in C#/Java is because C#/Java do not support multiple inheritance." - The assertion that this is the reason is completely false. Interfaces exist in Java so as not to conflate the concepts of conformation to a contract and shared implementation. This is a common misconception among C++ developers attempting to disparage what is arguably a design more consistent with pure OO languages.

@Dave 2015-12-16 05:55:57

Objective-C also supports this via Protocols and goes a step further (confusingly at first) by making Protocol method implementation optional. This has provided Objective-C with much of what C++ will soon get via Concepts.

@Deduplicator 2016-01-07 18:32:10

@Dave: Really? Objective-C has compile-time evaluation, and templates?

@Dave 2016-01-23 10:18:45

@Deduplicator - I'm referring to the key property of concepts being that they allow a callee (in your case a template) to specify constraints on the API that an argument must/should support where those constraints are expressed within the declaration or definition of the callee rather than within the class hierarchy of the argument. No Objective-C doesn't have templates. Templates in this discussion are the things being improved by a "concept" similar in some respects to Objective-C's protocols. But I'm sure you already knew that.

@fdsfdsfdsfds 2018-03-29 17:18:18

then give an example of what you call multiple inheritance, becos so far it seems java can do it but not c++, java can implment many interface

@Joel Coehoorn 2018-03-29 17:23:39

c++ can directly inherit from many classes. java can only directly inherit from one class.

@陳 力 2017-11-07 01:22:20

Here is the definition of abstract class in c++ standard



An abstract class is a class that can be used only as a base class of some other class; no objects of an abstract class can be created except as subobjects of a class derived from it. A class is abstract if it has at least one pure virtual function.

@Dima 2008-11-25 17:27:01

There is no concept of "interface" per se in C++. AFAIK, interfaces were first introduced in Java to work around the lack of multiple inheritance. This concept has turned out to be quite useful, and the same effect can be achieved in C++ by using an abstract base class.

An abstract base class is a class in which at least one member function (method in Java lingo) is a pure virtual function declared using the following syntax:

class A
  virtual void foo() = 0;

An abstract base class cannot be instantiated, i. e. you cannot declare an object of class A. You can only derive classes from A, but any derived class that does not provide an implementation of foo() will also be abstract. In order to stop being abstract, a derived class must provide implementations for all pure virtual functions it inherits.

Note that an abstract base class can be more than an interface, because it can contain data members and member functions that are not pure virtual. An equivalent of an interface would be an abstract base class without any data with only pure virtual functions.

And, as Mark Ransom pointed out, an abstract base class should provide a virtual destructor, just like any base class, for that matter.

@OscarRyz 2008-11-25 17:32:33

More than "lack of multiple inheritance" I would say, to replace multiple inheritance. Java was designed like this from the beginning because multiple inheritance create more problems than what it solves. Good answer

@Dima 2008-11-25 17:40:31

Oscar, that depends on whether you are a C++ programmer who learned Java or vice versa. :) IMHO, if used judiciously, like almost anything in C++, multiple inheritance solves problems. An "interface" abstract base class is an example of a very judicious use of multiple inheritance.

@curiousguy 2012-08-16 03:24:52

@OscarRyz Wrong. MI only creates problem when misused. Most alleged problems with MI would also come up with alternate designs (without MI). When people have a problem with their design with MI, it's the fault of MI; if they have a design problem with SI, it's their own fault. "Diamond of death" (repeated inheritance) is a prime example. MI bashing is not pure hypocrisy, but close.

@Marek Stanley 2015-03-25 17:22:14

Semantically, interfaces are different from abstract classes, so Java's interfaces are not just a technical workaround. The choice between defining an interface or an abstract class is driven by semantics, not technical considerations. Let's imagine some interface "HasEngine": that's an aspect, a feature, and it can be applied to / implemented by very different types (whether classes or abstract classes), so we'll define an interface for that, not an abstract class.

@Dima 2015-03-25 17:28:48

@MarekStanley, you may be right, but I wish you'd picked a better example. I like to think of it in terms of inheriting an interface vs. inheriting an implementation. In C++ you can either inherit both interface and implementation together (public inheritance) or you can inherit only the implementation (private inheritance). In Java you have the option of inheriting just the interface, without an implementation.

@Justin Time 2 Reinstate Monica 2016-04-08 18:53:27

@curiousguy That sums it up pretty well. Generally speaking, it's more difficult to use multiple inheritance properly than it is to use single inheritance properly, but merely being more difficult doesn't mean it's impossible. An example would be something like this: class Button; class Image; class ClickableIcon : public Button, public Image {}; . If they're designed properly, Image will supply the graphics functionality and Button will supply the interactive functionality, with no overlap that could cause issues, while ClickableIcon itself handles the functionality the button is for.

@Justin Time 2 Reinstate Monica 2016-04-08 19:32:16

...I could've worded that example much better. Button provides the interactive code, Image provides the graphics code, and ClickableIcon provides code specific to itself, as well as any code needed to weld the two parent classes together. As long as the two classes are designed properly, and have no overlapping member names, the class should be entirely viable, and easier to implement than if one or both was an interface.

@Mark Ingram 2009-10-13 19:53:38

If you're using Microsoft's C++ compiler, then you could do the following:

struct __declspec(novtable) IFoo
    virtual void Bar() = 0;

class Child : public IFoo
    virtual void Bar() override { /* Do Something */ }

I like this approach because it results in a lot smaller interface code and the generated code size can be significantly smaller. The use of novtable removes all reference to the vtable pointer in that class, so you can never instantiate it directly. See the documentation here - novtable.

@Flexo 2011-09-17 13:09:57

I don't quite see why you used novtable over standard virtual void Bar() = 0;

@Mark Ingram 2011-09-20 14:44:43

It's in addition to (I've just noticed the missing = 0; which I've added). Read the documentation if you don't understand it.

@Flexo 2011-09-20 14:47:33

I read it without the = 0; and assumed it was just a non-standard way of doing exactly the same.

@bradtgmurray 2008-11-25 16:53:31

Make a class with pure virtual methods. Use the interface by creating another class that overrides those virtual methods.

A pure virtual method is a class method that is defined as virtual and assigned to 0.

class IDemo
        virtual ~IDemo() {}
        virtual void OverrideMe() = 0;

class Child : public IDemo
        virtual void OverrideMe()
            //do stuff

@Evan Teran 2008-11-26 08:33:13

you should have a do nothing destructor in IDemo so that it is defined behavior to do: IDemo *p = new Child; /*whatever */ delete p;

@Cemre 2012-01-31 22:26:06

Why is the OverrideMe method in Child class is virtual ? Is that necessary ?

@PowerApp101 2012-02-12 11:15:18

@Cemre - no it's not necessary, but it doesn't hurt either.

@Kevin 2014-10-03 20:47:24

It is generally a good idea to keep the keyword 'virtual' whenever overriding a virtual method. Though not required, it can make the code clearer - otherwise, you have no indication that that method could be used polymorphically, or even exists in the base class.

@keyser 2014-11-26 21:34:18

@Kevin Except with override in C++11

@Phylliida 2015-10-14 16:40:38

Don't forget the semicolons at the end of the class declarations.

@Justin Time 2 Reinstate Monica 2019-07-28 16:41:44

It's not necessary to declare Child::OverrideMe() as virtual, @Cemre, because IDemo::OverrideMe() makes Child::OverrideMe() implicitly virtual. Having an indication that it's a virtual function (such as virtual, or better yet, override in C++11 or later) will serve as a reminder for programmers, with override in particular also helping the compiler check that it does indeed override something.

@lorro 2016-07-26 15:29:25

While it's true that virtual is the de-facto standard to define an interface, let's not forget about the classic C-like pattern, which comes with a constructor in C++:

struct IButton
    void (*click)(); // might be std::function(void()) if you prefer

    IButton( void (*click_)() )
    : click(click_)

// call as:
// (button.*click)();

This has the advantage that you can re-bind events runtime without having to construct your class again (as C++ does not have a syntax for changing polymorphic types, this is a workaround for chameleon classes).


  • You might inherit from this as a base class (both virtual and non-virtual are permitted) and fill click in your descendant's constructor.
  • You might have the function pointer as a protected member and have a public reference and/or getter.
  • As mentioned above, this allows you to switch the implementation in runtime. Thus it's a way to manage state as well. Depending on the number of ifs vs. state changes in your code, this might be faster than switch()es or ifs (turnaround is expected around 3-4 ifs, but always measure first.
  • If you choose std::function<> over function pointers, you might be able to manage all your object data within IBase. From this point, you can have value schematics for IBase (e.g., std::vector<IBase> will work). Note that this might be slower depending on your compiler and STL code; also that current implementations of std::function<> tend to have an overhead when compared to function pointers or even virtual functions (this might change in the future).

@Yeo 2015-09-27 18:27:29

I'm still new in C++ development. I started with Visual Studio (VS).

Yet, no one seems to mentioned the __interface in VS (.NET). I am not very sure if this is a good way to declare an interface. But it seems to provide an additional enforcement (mentioned in the documents). Such that you don't have to explicitly specify the virtual TYPE Method() = 0;, since it will be automatically converted.

__interface IMyInterface {
   HRESULT CommitX();
   HRESULT get_X(BSTR* pbstrName);

However, I don't use it because I am concern about the cross platform compilation compatibility, since it only available under .NET.

If anyone do have anything interesting about it, please share. :-)


@Mark Ransom 2008-11-25 17:11:33

To expand on the answer by bradtgmurray, you may want to make one exception to the pure virtual method list of your interface by adding a virtual destructor. This allows you to pass pointer ownership to another party without exposing the concrete derived class. The destructor doesn't have to do anything, because the interface doesn't have any concrete members. It might seem contradictory to define a function as both virtual and inline, but trust me - it isn't.

class IDemo
        virtual ~IDemo() {}
        virtual void OverrideMe() = 0;

class Parent
        virtual ~Parent();

class Child : public Parent, public IDemo
        virtual void OverrideMe()
            //do stuff

You don't have to include a body for the virtual destructor - it turns out some compilers have trouble optimizing an empty destructor and you're better off using the default.

@xan 2008-11-25 17:52:38

Virtual desctuctor++! This is very important. You may also want to include pure virtual declarations of the operator= and copy constructor definitions to prevent the compiler auto-generating those for you.

@Fred Larson 2008-11-25 19:06:00

An alternative to a virtual destructor is a protected destructor. This disables polymorphic destruction, which may be more appropriate in some circumstances. Look for "Guideline #4" in

@bradtgmurray 2009-07-17 14:28:52

If you know you're not going to delete the class through a base class, you don't need the virtual destructor. However, it's never really harmful to make the destructor virtual anyway (except for one vtable lookup, oh no!).

@Pavel Minaev 2009-12-31 09:04:51

One other option is to define a pure virtual (=0) destructor with a body. The advantage here is that the compiler can, theoretically, see that vtable has no valid members now, and discard it altogether. With a virtual destructor with a body, said destructor can be called (virtually) e.g. in the middle of construction via this pointer (when constructed object is still of Parent type), and therefore the compiler has to provide a valid vtable. So if you don't explicitly call virtual destructors via this during construction :) you can save on code size.

@Lumi 2012-03-10 21:40:33

Forty moons ago, but anyway - @Mark Ransom, you wrote: "This allows you to pass pointer ownership to another party without exposing the base class." Did you mean "sub class"? Because then in your comment you wrote: "If you know you're not going to delete the class through a base class, you don't need the virtual destructor." - Sorry if my remark doesn't make sense - I'm a C++ noob and trying to learn from these questions and answers.

@Mark Ransom 2012-03-10 22:42:04

@Lumi, now that I think about it you're absolutely correct. The interface is a base class because the concrete class derives from it and implements the methods. I should fix this. Give yourself a gold star for being the first to notice, I'm sure this answer has been viewed a thousand times.

@Lumi 2012-03-10 22:49:17

@MarkRansom, thanks for the virtual gold star. :) Meanwhile, I figured out you must have meant what I surmised you had meant because I got to the bottom of the page where Carlos' answer makes the point clear with a code sample. Thanks for your feedback after such a long time! -- Best, Michael

@curiousguy 2012-08-16 03:26:55

@PavelMinaev "With a virtual destructor with a body, said destructor can be called (virtually) e.g. in the middle of construction" seriously?

@Mark Ransom 2012-08-16 03:31:36

@curiousguy, yes you can call a destructor in the middle of construction when you throw from the constructor of a derived class.

@curiousguy 2012-08-16 03:49:19

But virtually?!!

@Pavel Minaev 2012-08-16 18:24:12

Consider an inheritance hierarchy: Base <- Derived <- MostDerived. You are in Derived ctor. You call a global function that takes a Base* argument, passing it this. That function can explicitly invoke the destructor via the pointer, and it has to be dispatched virtually.

@Mark Ransom 2012-08-16 19:18:33

@PavelMinaev, wouldn't it be UB to destroy an object explicitly before it's finished constructing? I can see the MostDerived constructor getting very unhappy. At least with destroying via throw the remainder of the construction is bypassed.

@Pavel Minaev 2012-08-17 00:01:37

It would certainly be UB by the time it gets to the ctor of MostDerived, but I don't see anything that would make e.g. this->~Foo() in a ctor UB all by itself. Consider the case where you destruct it, and then never return to the ctor (e.g. just sit there in an infinite loop, taking and processing input). Inside that loop, your behavior would be well-defined, so far as I can see.

@Tim 2012-08-24 22:49:02

How typical of a C++ answer that the top answer doesn't directly answer the question (though obviously the code is perfect), instead it optimizes the simple answer.

@Sean 2013-01-15 03:19:07

Don't forget that in C++11 you can specify the override keyword to allow for compile-time argument and return value type checking. For example, in the declaration of Child virtual void OverrideMe() override;

@Mark Ransom 2013-01-15 03:42:13

@Sean, this answer predates C++11 by a few years, but you make a good point - thanks!

@Maxim Egorushkin 2013-01-16 07:29:34

I agree with @PavelMinaev, there is little if any reason for the destructor to be non-pure virtual.

@Chris 2013-05-22 04:29:20

Also note that GCC cannot handle pure-virtual destructors and you need to define them:

@Griddo 2014-03-12 08:43:52

@Chris I'm a little bit confused now regarding Mark Ransoms note on compiler optimization and your comment. Sounds like the former suggests using pure virtual destructors while the latter forbids it. Did I misunderstand something? If not, is there a general solution for this or is it compiler dependent?

@Chris 2014-03-12 09:57:33

@Griddo No, you understand quite right. Mark Ransom suggests not defining the virtual destructor while GCC requires you to do so. I don't really think there is a general solution for this other than clutter your code with #ifdef and compiler checks but in this case I'd rather just go with defining it and maybe lose some optimization benefits on some compilers.

@Zachary Kraus 2014-12-09 22:49:19

@xan Can you please explain the reasoning behind wanting to make the assignment operator and copy constructor pure virtual in the IDemo class.

@Mark Ransom 2014-12-10 00:01:48

@ZacharyKraus an interface should be a very small subset of the class that actually implements the interface; in particular it won't have any data members. That almost guarantees that the compiler-generated copy and assignment operators will do the wrong thing. If you want to implement them yourself then knock yourself out, but it's usually not necessary - you access an interface via a pointer, and copies of the pointer are OK as long as you've handled ownership.

@xan 2014-12-10 16:57:14

@ZacharyKraus: What MarkRansom said. If you are declaring an interface in this way, it's highly unlikely that the compiler's auto-generated attempts at these would be correct. Thus, it's safer to explicitly declare them pure virtual yourself and make sure that you can't accidental fall into the trap of using them.

@Zachary Kraus 2014-12-17 00:28:06

@MarkRansom I now understand the reasoning but I still have 2 questions that I just don't understand. The first is does the compiler automatically create the assignment and copy constructor for ever class even if you never use them in your code. Second, can you accidentally trigger either assignment or copy constructor when the object is a pointer?

@Mark Ransom 2014-12-17 02:23:48

@ZacharyKraus their presence or absence isn't detectable unless you call them, so by the "as-if" rule it could go either way - I suspect most compilers don't. You can generate a call with e.g. *a = *b but I grant you it's not common.

@Deduplicator 2016-01-07 19:28:37

Also, it simply daoesn't actually matter, as assinging / copying the interface doesn't do anything.

@Sparker0i 2018-08-10 18:57:17

Inside Child , is it still necessary to write OverrideMe() as virtual void ?

@Mark Ransom 2018-08-10 20:18:27

@Sparker0i virtual is not necessary since the base class declaration already made it virtual, but it's good practice to be consistent. void is still necessary.

@L. F. 2019-06-15 13:15:14

It would be nice if you mention that the destructor can be made pure virtual if no other function is available.

@Glinka 2019-06-26 14:40:45

What one should do with the warning that IDemo "has no out-of-line virtual method definitions"?

@gnzlbg 2013-06-25 13:51:08

In C++11 you can easily avoid inheritance altogether:

struct Interface {
  explicit Interface(SomeType& other)
  : foo([=](){ return other.my_foo(); }), 
    bar([=](){ return other.my_bar(); }), /*...*/ {}
  explicit Interface(SomeOtherType& other)
  : foo([=](){ return other.some_foo(); }), 
    bar([=](){ return other.some_bar(); }), /*...*/ {}
  // you can add more types here...

  // or use a generic constructor:
  template<class T>
  explicit Interface(T& other)
  : foo([=](){ return; }), 
    bar([=](){ return; }), /*...*/ {}

  const std::function<void(std::string)> foo;
  const std::function<void(std::string)> bar;
  // ...

In this case, an Interface has reference semantics, i.e. you have to make sure that the object outlives the interface (it is also possible to make interfaces with value semantics).

These type of interfaces have their pros and cons:

  • They require more memory than inheritance based polymorphism.
  • They are in general faster than inheritance based polymorphism.
  • In those cases in which you know the final type, they are much faster! (some compilers like gcc and clang perform more optimizations in types that do not have/inherit from types with virtual functions).

Finally, inheritance is the root of all evil in complex software design. In Sean Parent's Value Semantics and Concepts-based Polymorphism (highly recommended, better versions of this technique are explained there) the following case is studied:

Say I have an application in which I deal with my shapes polymorphically using the MyShape interface:

struct MyShape { virtual void my_draw() = 0; };
struct Circle : MyShape { void my_draw() { /* ... */ } };
// more shapes: e.g. triangle

In your application, you do the same with different shapes using the YourShape interface:

struct YourShape { virtual void your_draw() = 0; };
struct Square : YourShape { void your_draw() { /* ... */ } };
/// some more shapes here...

Now say you want to use some of the shapes that I've developed in your application. Conceptually, our shapes have the same interface, but to make my shapes work in your application you would need to extend my shapes as follows:

struct Circle : MyShape, YourShape { 
  void my_draw() { /*stays the same*/ };
  void your_draw() { my_draw(); }

First, modifying my shapes might not be possible at all. Furthermore, multiple inheritance leads the road to spaghetti code (imagine a third project comes in that is using the TheirShape interface... what happens if they also call their draw function my_draw ?).

Update: There are a couple of new references about non-inheritance based polymorphism:

@doc 2014-10-15 17:28:08

TBH inheritance is far more clear than that C++11 thing, which pretends to be an interface, but is rather a glue to bind some inconsistent designs. Shapes example is detached from reality and Circle class is a poor design. You should use Adapter pattern in such cases. Sorry if it will sound a little bit harsh, but try to use some real life library like Qt before making judgements about inheritance. Inheritance makes life much easier.

@gnzlbg 2014-10-15 17:42:58

It doesn't sound harsh at all. How is the shape example detached from reality? Could you give an example (maybe on ideone) of fixing Circle using the Adapter pattern? I'm interested to see its advantages.

@doc 2014-10-15 18:18:51

O.K. I will try to fit in this tiny box. First of all, you usually choose libraries like "MyShape" before you start writing your own application, to safe your work. Otherwise how could you know Square isn't already there? Foreknowledge? That's why it is detached from reality. And in reality if you choose to rely on "MyShape" library you can adopt to its interface from the very beginning. In shapes example there are many nonsenses (one of which is that you have two Circle structs), but adapter would look something like that ->

@doc 2014-10-15 20:22:51

As I mentioned Qt. Check this example ->‌​tml to see how robust inheritance altogether with virtual methods is. And with banned inheritance and that C++11 "interface" thing instead, am I supposed to implement every time ALL virtual methods that QWidget has? Would I need to delegate each call to check for example my custom widget position? On the other hand Qt must had become header only library, because of "interface" thing required to invoke my implementations.

@gnzlbg 2014-10-15 21:56:32

It is not detached from reality then. When company A buys company B and wants to integrate company B's codebase into A's, you have two completely independent code bases. Imagine each has a Shape hierarchy of different types. You cannot combine them easily with inheritance, and add company C and you have a huge mess. I think you should watch this talk: My answer is older, but you'll see the similarities. You don't have to reimplement everything all the time,you can provide an implementation in the interface, and choose a member function if available.

@gnzlbg 2014-10-15 22:16:29

There are also a couple of talks by Sean Parent about concept-based polymorphism that might be interesting to you.

@doc 2014-10-16 01:51:33

Mentioned Qt was owned by 3 companies (Trolltech, Nokia, Digia) but none of them did the thing you say. It is detached from reality. Give me an example of real world software where such code merging took place. Even if so you should use Adapter pattern. Providing implementation in interface like one in your answer means that I have to provide all virtual methods, which otherwise could be simply inherited.

@doc 2014-10-16 02:19:54

I've watched part of video and this is totally wrong. I never use dynamic_cast except for debugging purposes. Dynamic cast means theres something wrong with your design and designs in this video are wrong by design :). Guy even mentions Qt, but even here he is wrong - QLayout does not inherit from QWidget nor the other way around!

@gnzlbg 2014-10-16 09:15:50

I've updated the answer with reference in case you are interested into learning more about this. Those three companies you mention were all working using the same library. Inheritance becomes a huge problem when this is not the case. Examples of companies are shown in the Sean Parent talk about concept-based polymorphism.The links provided have more information than I can provide here.

@doc 2014-10-16 16:21:03

I've watched video on concept-based polymorphism. While the technique is interesting and may find some applications this can't replace inheritance based polymorphism (and this concept-based polymorphism still uses inheritance only hidden in private model structs). Polymorphism is not only for your internals, but also to provide a way application can interact with a library. Photoshop is not a library so it wasn't even considered in the video. I can't see any practical features in conecpt-based polymorphism that couldn't be achieved with IMO much cleaner inheritance.

@gnzlbg 2014-10-16 19:06:00

I agree that inheritance based polymorphism is very easy to use in C++ (this feature has full language support). In C for example it is very hard to do it. In Haskell, Rust, Scala.. you have traits and typeclasses which are kind of like language support for non-inheritance based polymorphism. I've used it in an app and was pretty happy with it. Mostly due to the performance boost it gave me (I can have vectors of each type, and a vector of interfaces, so I only use polymorphism where i really need it). We'll see how this evolves in C++, people have started talking about it fairly recently...

@doc 2014-10-17 02:58:52

Right. The problem is I can't see why inheritance is "the root of all evil". Such statement is ridiculous.

@gnzlbg 2014-10-18 08:39:33

Well the statement is more like "inheritance-based polymorphism is the root of all evil". After thinking a bit more about the solution you provided using the Adaptor pattern, the advantage I see about using a type-erased interface instead (like the one sean parent uses) is that your interface is in a single place, and you can extend its behavior and provide defaults via non-member non-friend functions. The interface is, however, way more complex to implement. The extension mechanism... its ADL vs not-ADL. If you go for ADL you are basically "stealing" function names from your users namespaces.

@doc 2014-10-18 15:06:31

And that's IMO bad, because you want to divide complex software into small logical pieces and inheritance helps you accomplish it. Having all kinds of objects (models in this specific case) degenerated to a single class is not convincing to me. How am I supposed to extend such concept-based interface if I don't have access to object_t internals nor I can't inherit after it? From what I see, I have to implement draw() function from scratch on my own and I am not binded to concept_t interface. Also, with virtual methods I can have default implementations, which I can override or not.

@doc 2014-10-18 15:59:55

Term "interface" comes from Java world. What Java doc has to say: "Implementing an interface allows a class to become more formal about the behavior it promises to provide. Interfaces form a contract between the class and the outside world, and this contract is enforced at build time by the compiler. If your class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile." (‌​l) Thing you are presenting is like world upside down.

@gnzlbg 2014-10-18 16:37:40

Exactly, and I think that it is the correct thing to do: "write your class first, make it model an interface later". It completely decouples your class implementation from modeling a given interface, and allows you to use your class in context you couldn't had thought of at the moment of writing it. C++ concepts, haskell typeclasses, rust/scala traits, and the Adaptor pattern you showed work this way. This same reasoning is behind the NVI idiom, but these other solutions decouple the design even more, since a class is not an interface anymore (in the "is a" sense of inheritance).

@doc 2014-10-18 16:58:02

This is a road to pure mess. Adapter pattern exists to bind incompatible interfaces, if necessary, but interfaces which already exist. I don't know why even use classes with approach "write your class first". This asks to come back to pure C. On what premise are you building your class if you don't know how it will interact with outer world? Say you used your own implementation of gnzlbg::vector in your class and I provide interface with my custom doc::vector and you have to convert input and output to your internals. Where's our code re-use and efficiency if you need to convert them?

@gnzlbg 2014-10-19 09:38:57

Note first, that an interface can wrap a type either by value, unique reference, or shared reference. Second, this problem with vector already exist since allocator is in the std::vector type. The solution is either to convert (which involves copy: expensive), or provide an iterator interface instead using e.g. Boost.Iterator.any_iterator (which uses the type-erasure described here, and is slow). Why do you say it asks to come back to pure C? The interfaces are type-safe, and can be very thin. I build my classes knowing that my knowledge about my problem (and my needs) will change with time.

@gnzlbg 2014-10-19 09:46:46

What would be the inheritance based solution if you cannot modify my code? The best I can come up with is: have a pure virtual base class vector, make yours inherit from it (always pay vtable), make your vectors function virtual (always pay this price), and use Adaptor pattern for my vector. The alternative would be, create a vector interface that adapts your vector and my vector. And use the interface when you need to polymorphically access your vector and my vector, but only in those places. And here when I say interface I mean mine, or one based on the adaptor pattern.

@gnzlbg 2014-10-19 10:06:08

@doc 2014-10-19 14:14:01

Wrapping type will not prevent you from reimplementing same functionality and doing very expensive conversion between vector types. Problem with vector does not exist if we both use either doc::vector or gnzlbg::vector on interface premise. You should learn how to properly use inheritance, because what you are saying now, does not make any sense!

@hims 2013-12-19 15:45:41

class Shape 
   // pure virtual function providing interface framework.
   virtual int getArea() = 0;
   void setWidth(int w)
      width = w;
   void setHeight(int h)
      height = h;
    int width;
    int height;

class Rectangle: public Shape
    int getArea()
        return (width * height); 
class Triangle: public Shape
    int getArea()
        return (width * height)/2; 

int main(void)
     Rectangle Rect;
     Triangle  Tri;


     cout << "Rectangle area: " << Rect.getArea() << endl;


     cout << "Triangle area: " << Tri.getArea() << endl; 

     return 0;

Result: Rectangle area: 35 Triangle area: 17

We have seen how an abstract class defined an interface in terms of getArea() and two other classes implemented same function but with different algorithm to calculate the area specific to the shape.

@guitarflow 2014-03-26 10:55:26

This is not what is considered an interface! That's just an abstract base class with one method that needs to be overridden! Interfaces are typically objects that contain only method definitions - a "contract" other classes have to fulfill when they implement the interface.

@Carlos C Soto 2012-03-05 17:53:12

As far I could test, it is very important to add the virtual destructor. I'm using objects created with new and destroyed with delete.

If you do not add the virtual destructor in the interface, then the destructor of the inherited class is not called.

class IBase {
    virtual ~IBase() {}; // destructor, use it to call destructor of the inherit classes
    virtual void Describe() = 0; // pure virtual method

class Tester : public IBase {
    Tester(std::string name);
    virtual ~Tester();
    virtual void Describe();
    std::string privatename;

Tester::Tester(std::string name) {
    std::cout << "Tester constructor" << std::endl;
    this->privatename = name;

Tester::~Tester() {
    std::cout << "Tester destructor" << std::endl;

void Tester::Describe() {
    std::cout << "I'm Tester [" << this->privatename << "]" << std::endl;

void descriptor(IBase * obj) {

int main(int argc, char** argv) {

    std::cout << std::endl << "Tester Testing..." << std::endl;
    Tester * obj1 = new Tester("Declared with Tester");
    delete obj1;

    std::cout << std::endl << "IBase Testing..." << std::endl;
    IBase * obj2 = new Tester("Declared with IBase");
    delete obj2;

    // this is a bad usage of the object since it is created with "new" but there are no "delete"
    std::cout << std::endl << "Tester not defined..." << std::endl;
    descriptor(new Tester("Not defined"));

    return 0;

If you run the previous code without virtual ~IBase() {};, you will see that the destructor Tester::~Tester() is never called.

@Lumi 2012-03-10 22:43:39

Best answer on this page as it makes the point by supplying a practical, compilable example. Cheers!

@Alessandro L. 2013-01-17 14:01:03

Testet::~Tester() runs only when the obj is "Declared with Tester".

@Chris Reid 2017-05-26 07:46:57

Actually, the string privatename's destructor will be called, and in memory, that is all there will be allocated for. As far as the runtime is concerned, when all the concrete members of a class are destroyed, so is the class instance. I tried a similar experiment with a Line class that had two Point structs and found both the structs were destructed (Ha!) upon a delete call or return from the encompassing function. valgrind confirmed 0 leak.

@Rexxar 2008-11-25 18:48:00

My answer is basically the same as the others but I think there are two other important things to do:

  1. Declare a virtual destructor in your interface or make a protected non-virtual one to avoid undefined behaviours if someone tries to delete an object of type IDemo.

  2. Use virtual inheritance to avoid problems whith multiple inheritance. (There is more often multiple inheritance when we use interfaces.)

And like other answers:

  • Make a class with pure virtual methods.
  • Use the interface by creating another class that overrides those virtual methods.

    class IDemo
            virtual void OverrideMe() = 0;
            virtual ~IDemo() {}


    class IDemo
            virtual void OverrideMe() = 0;
            ~IDemo() {}


    class Child : virtual public IDemo
            virtual void OverrideMe()
                //do stuff

@Robocide 2011-07-03 07:22:00

there is no need for virtual inheritance as you do not have any data members in an interface.

@Knarf Navillus 2012-08-01 00:22:57

Virtual inheritance is important for methods as well. Without it, you will run into ambiguities with OverrideMe(), even if one of the 'instances' of it is pure virtual (just tried this myself).

@curiousguy 2012-08-16 03:25:24

@Avishay_ "there is no need for virtual inheritance as you do not have any data members in an interface." Wrong.

@mMontu 2012-09-19 17:55:50

Notice that virtual inheritance may not work on some gcc versions, as version 4.3.3 which is shipped with WinAVR 2010:

@Wolf 2014-03-14 11:06:41

-1 for having a non-virtual protected destructor, sorry

@Luc Hermitte 2008-11-25 17:49:00

You can also consider contract classes implemented with the NVI (Non Virtual Interface Pattern). For instance:

struct Contract1 : boost::noncopyable
    virtual ~Contract1();
    void f(Parameters p) {
        assert(checkFPreconditions(p)&&"Contract1::f, pre-condition failure");
        // + class invariants.
        // Check post-conditions + class invariants.
    virtual void do_f(Parameters p) = 0;
class Concrete : public Contract1, public Contract2
    virtual void do_f(Parameters p); // From contract 1.
    virtual void do_g(Parameters p); // From contract 2.

@user2067021 2011-11-01 00:39:13

For other readers, this Dr Dobbs article "Conversations: Virtually Yours" by Jim Hyslop and Herb Sutter elaborates a bit more on why one might want to use the NVI.

@user2067021 2011-11-01 01:15:11

And also this article "Virtuality" by Herb Sutter.

@Rodyland 2008-11-25 22:02:19

All good answers above. One extra thing you should keep in mind - you can also have a pure virtual destructor. The only difference is that you still need to implement it.


    --- header file ----
    class foo {
      foo() {;}
      virtual ~foo() = 0;

      virtual bool overrideMe() {return false;}

    ---- source ----

The main reason you'd want to do this is if you want to provide interface methods, as I have, but make overriding them optional.

To make the class an interface class requires a pure virtual method, but all of your virtual methods have default implementations, so the only method left to make pure virtual is the destructor.

Reimplementing a destructor in the derived class is no big deal at all - I always reimplement a destructor, virtual or not, in my derived classes.

@Johann Gerell 2008-11-26 07:57:32

Why, oh why, would anyone want to make the dtor in this case pure virtual? What would be the gain of that? You'd just force something onto the derived classes that they likely have no need to include - a dtor.

@Rodyland 2008-12-02 20:27:42

Updated my answer to answer your question. Pure virtual destructor is a valid way to achieve (the only way to achieve?) an interface class where all methods have default implementations.

@Uri 2008-11-25 17:35:34

A little addition to what's written up there:

First, make sure your destructor is also pure virtual

Second, you may want to inherit virtually (rather than normally) when you do implement, just for good measures.

@Tim 2008-11-25 18:51:54

Why inherit virtually?

@Uri 2008-11-25 19:09:51

I like virtual inheritance because conceptually it means that there is only one instance of the inherited class. Admittedly, the class here does not have any space requirement so it may be superfluous. I haven't done MI in C++ for a while, but wouldn't nonvirtual inheritance complicate upcasting?

@Johann Gerell 2008-11-26 07:55:38

Why, oh why, would anyone want to make the dtor in this case pure virtual? What would be the gain of that? You'd just force something onto the derived classes that they likely have no need to include - a dtor.

@Uri 2008-11-26 09:14:50

If there is a situation that an object would be destroyed through a pointer to the interface, you should make sure that the destructor is virtual...

@Rodyland 2008-12-05 03:24:31

There is nothing wrong with a pure virtual destructor. It's not necessary, but there's nothing wrong with it. Implementing a destructor in a derived class is hardly a huge burden on the implementor of that class. See my answer below for why you'd do this.

@doc 2014-10-17 12:33:51

+1 for virtual inheritance, because with interfaces it is more likely that class will derive interface from two or more paths. I opt for protected destructors in interfaces tho.

@Justin Time 2 Reinstate Monica 2016-04-08 20:14:51

@JohannGerell I believe the intention behind pure virtual destructors is to prevent a vtable from being generated unless a class that inherits from your interface class is itself inherited from. If this is the intention, though, the destructor should be both declared pure virtual and defined, as so: class Base { public: ~Base() = 0; }; Base::~Base() {}, to allow the compiler to generate default constructors for derived classes

Related Questions

Sponsored Content

23 Answered Questions

[SOLVED] What is the "-->" operator in C++?

29 Answered Questions

26 Answered Questions

37 Answered Questions

34 Answered Questions

[SOLVED] What is the difference between an interface and abstract class?

1 Answered Questions

[SOLVED] The Definitive C++ Book Guide and List

  • 2008-12-23 05:23:56
  • grepsedawk
  • 2246858 View
  • 4246 Score
  • 1 Answer
  • Tags:   c++ c++-faq

7 Answered Questions

[SOLVED] Difference between abstract class and interface in Python

34 Answered Questions

[SOLVED] Interface vs Abstract Class (general OO)

10 Answered Questions

[SOLVED] Calling the base constructor in C#

Sponsored Content