Inherit Stl Containers Publicly

Part of the CppHeresy.

Let's see, what else is a mess. Oh yes, there's all that drivel where we compose a container and have a method that just calls its methods. Screw that - InheritStlContainersPublicly. Oh, you think that will break encapsulation? BloodyOath it would, except that python is doing your encapsulation for you. Well then, what about when you have a class with two containers? ReFactor it. But wouldn't that result in MI? Maybe not with StlStyle, but even if it does, MultipleInheritanceIsNotEvil.

In orthodox (non-Python) CeePlusPlus, an alternative is to inherit privately and add using declarations as needed. It is less typing than composition and it avoids problems like the lack of virtual destructor.

This is a much better alternative. It's not so much that it is heresy to publicly inherit from STL containers. Who cares about heresy? It's that it just isn't a good idea and can lead to subtle bugs, especially if you use any polymorphism. You are much better off using simple private inheritance (i.e. ImplementationInheritance) and explicitly publishing the members you want with using declarations. -- RobertDiFalco

It is usually advised not to derive a class from STL (StandardTemplateLibrary). This is because STL does not provide virtual destructors and so can cause a problem if you destroy it from the base class. You can embed the STL class and inline all of the calls you want to use from it. This will only cost you programming time now and will leave you with a more robust class for future modifications. -- WayneMack

True with public inheritance. However ill advised, you can avoid the problem with private inheritance.

Ah, I wasn't familiar with using plus private inheritance. Yes, this improves the CppHeresy - thanks! --PeterMerel

Explanation please?

Attention all alleged C++ heretics. The bonding layer between C++ and the scripting layer is a "PublishedInterface" - that's one step above a "PublicInterface". So, per EncapsulationIsHierarchical, wide and reckless interfaces within one capsule are okay so long as you don't >publish< them.

If you published them, you'd be responsible for maintaining them, going forward. That would inhibit refactoring.

So if we see that the commandment "make PublishedInterfaces as narrow as possible" is being followed to the letter, then this is CppOrthodoxy, not CppHeresy, and our sophomoric attempts to disconcert the gurus must lead elsewhere.

Sorry. --PhlIp

CategoryCpp CategoryContainer