Question

I often read this statements on Stack Overflow. Personally, I don’t find any problem with this, unless I am using it in a polymorphic way; i.e. where I have to use virtual destructor.

If I want to extend/add the functionality of a standard container then what is a better way than inheriting one? Wrapping those container inside a custom class requires much more effort and is still unclean.

Answer 1

Maybe many people here will not like this answer, but it is time for some heresy to be told and yes … be told also that "the king is naked!"

All the motivation against the derivation are weak. Derivation is not different than composition. It’s just a way to "put things together".
Composition puts things together giving them names, inheritance does it without giving explicit names.

If you need a vector that has the same interface and implementation of std::vector plus something more, you can:

• use composition and rewrite all the embedded object function prototypes implementing function that delegates them (and if they are 10000… yes: be prepared to rewrite all those 10000) or…

• inherit it and add just what you need (and … just rewrite constructors, until C++ lawyers will decide to let them be inheritable as well: I still remember 10 year ago zealot discussion about "why ctors cannot call each other" and why it is a "bad bad bad thing" … until C++11 permitted it and suddenly all those zealots shut up!) and let the new destructor be non-virtual as it was in the original one.

Just like for every class that has some virtual method and some not, you know you cannot pretend to invoke the non-virtual method of derived by addressing the base, the same applies for delete. There is no reason just for delete to pretend any particular special care.

A programmer who knows that whatever is not virtual isn’t callable addressing the base, also knows not to use delete on your base after allocating your derived.

All the "avoid this", "don’t do that", always sound as "moralization" of something that is natively agnostic. All the features of a language exist to solve some problem. The fact a given way to solve the problem is good or bad depends on the context, not on the feature itself.

If what you’re doing needs to serve many containers, inheritance is probably not the way (you have to redo for all). If it is for a specific case … inheritance is a way to compose. Forget OOP purisms: C++ is not a "pure OOP" language, and containers are not OOP at all.