13

I have a base class that is not polymorphic, but I want to prevent it from being instantiated. Should I give this base class a pure virtual destructor to prevent it from being instantiated? But is it wrong or bad practice to give a non-polymorphic base class a virtual destructor?

pkdc
  • 173
  • 2
  • 13
  • making the destructor private does not prevent the class from being instantiated. – 463035818_is_not_an_ai Jul 21 '15 at 11:13
  • 1
    possible duplicate of [C++: any way to prevent any instantiation of an abstract base class?](http://stackoverflow.com/questions/6272445/c-any-way-to-prevent-any-instantiation-of-an-abstract-base-class) – phuclv Jul 21 '15 at 11:43
  • it's a little bit similar to [singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern) where constructor is made private to prevent more than 1 object from instantiation – phuclv Jul 21 '15 at 11:44

3 Answers3

28

To prevent a base class from being instantiated make all constructors protected.

Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136
  • That's right, thanks. But this gives me another question, if I can just make all the constructors protected in a class to prevent it from being instantiated, why should there be abstract classes in the first place? – pkdc Jul 21 '15 at 10:57
  • 3
    @pkdc To "force" you to override functions. – nwp Jul 21 '15 at 11:01
  • 5
    They're different cases. A class becomes abstract in C++ by declaring one of its members to be 'pure virtual', make it most of all an *incomplete* class. That is why C++ doesn't need the `abstract` keyword as it can be automatically deferred from the presence of at least one pure virtual. In your case however the class is functionally *complete*, it just should not be instantiated for other reasons. Which makes the obvious solution to prevent invocations of the constructor. – Niels Keurentjes Jul 21 '15 at 11:02
  • 4
    @pkdc, The main purpose of abstract class is not to restrict instantiation but it is to force the user to follow a prototype. By introducing pure virtual functions we tell the user that you must redefine(override) these functions in your derived classes. – paper.plane Jul 21 '15 at 11:05
2

keep the ctor/dtor in protected scope.

paper.plane
  • 1,201
  • 10
  • 17
-7

Base classes in C++ are adviced to sport a virtual destructor. C++ is a really old programming language, and in case of not having a virtual destructor, an object of a derived class could be partially or incorrectly destroyed.

Certainly, a pure virtual destructor would prevent any instances of this class being created, but I think that, in order to make it clear that you don't expect this class to be instantiated, you could also create the constructors protected, as @Niels has pointed out in his answer.

Hope this helps.

Baltasarq
  • 12,014
  • 3
  • 38
  • 57
  • 2
    *"C++ is a really old programming language, and in case of not having a virtual destructor, an object of a derived class could be partially or incorrectly destroyed."* - C++ has solid reasons for not making all destructors virtual - efficiency, binary layout compatibility, utility in shared memory etc. - it has nothing to do with "being old", and the implication that an older language is in some way inherently compromised is flawed. – Tony Delroy Jul 21 '15 at 11:10
  • Oh, dear. I think I've created a flame war unconsciously. Sorry, I don't agree. C++ is indeed a really old programming language, when a compiler had to compromise a lot in use of memory and efficiency. Thus, it was logical to leave many decisions to the programmer. This is no longer true, and the compiler should be a lot smarter than it is now. Efficiency and other matters can be automatically handled, it is not so difficult. After all, many current programming languages do it. Oh, and C++ is not compromised. You just need to exactly know what you are doing. – Baltasarq Jul 21 '15 at 11:52
  • 4
    @Baltasarq I must also disagree with your opinion on this. C++ is still in use **because** of its focus on efficiency and all the power it leaves to the developer. C++ has been updated several times since its 1978 inception and still allows non-virtual destructors because its unlimited freedom to fxck up is its main reason for still having a reason to live. If you're writing a program that doesn't require manual control over such decisions, C++ is simply not the right tool, and you should be using C# or Java instead. If performance is vital C and C++ are still the *right tools for the job*. – Niels Keurentjes Jul 21 '15 at 12:01
  • It is unfortunate that so strong opinions prevent from discussion. Anyway, this is not the right place. @Tony D, yes, I've written a few compilers but obviously I was not talking about me. Optimizations like removing virtual calls are regularly done inside the JVM. I'm not saying C++ is useless, just saying it's showing its age. – Baltasarq Jul 21 '15 at 17:00