Why inheritance and not composition?

[abin-z]

template <typename Comparator>
class IniSectionBase : public std::map<std::string, IniField, Comparator>
{
  // ...
}

It's great to see such a great open source library!
But I have a question: Inheriting standard library containers is generally not recommended. The recommended practice is to compose.

Reason: None of the STL containers are designed to be used as base classes, so they do not have virtual destructors defined; this may lead to resource leaks if you point to a dynamically-allocated derived class object with a pointer to the base class and delete the pointer!

Are there any considerations for using inheritance instead of composition in your open source library?

I hope to hear from you.

很高兴看到如此优秀的开源库!
但是我有一个疑问: 通常来说不推荐继承标准库容器. 推荐的做法是组合.

原因: 所有的 STL 容器都未被设计为作为基类来使用，因此它们都没有定义虚析构函数；这样如果你用基类指针指向动态分配的派生类对象并 delete 该指针可能会导致资源泄漏！

你的开源库使用继承而不是组合是有什么考量吗?

希望能得到你的回复!

[Rookfighter]

Hi @abin-z,

thanks for your issue, you are absolutely right! As you say, the constructor of IniSectionBase (or IniFileBase) would not be called if the following conditions are met:

• IniSectionBase (or IniFileBase) is allocated on the heap
• the corresponding IniSectionBase (or IniFileBase) object is freed via a pointer of type std::map*

I have created an example of the behavior on compiler explorer to illustrate this: https://godbolt.org/z/Mrjrh6aWq

So I am fully aware of this issue, but I still made this design decision to use inheritance and not composition because:

• by inheriting from std::map you get all of its standard functionality for free for IniSectionBase and IniFileBase
  • this includes: methods for iterators, correct move semantics, handling initializer lists, constexpr methods, etc.
  • also IniSectionBase and IniFileBase automatically inherit the new functionality of the latest C++ standards (which ever you use)
• using composition the library would have to expose all relevant methods of std::map itself, it would have to distinguish between different C++ standards (not all methods are available on all standards), etc.

In general I designed it this way, because it keeps the library small and lean, easy to use (standard interface) and especially easy to maintain and stay up to date.

I accepted the potential memory leak knowingly because:

• IniSectionBase is typically only created and maintained by IniFileBase, where it is handled in a non-polymorphic way, so a leak will not appear within this usage
• IniFileBase is typically created on the stack or heap and not used in a polymorphic way
  • I cannot really see the use case that someone willingly puts a IniFileBase into a std::map* pointer
  • However, if someone does this IMO the person is fully aware of polymorphism and that IniFileBase inherits from std::map, so this person should also be able to consider the non-virtual destructor of std::map

In general, I decided for easier maintenance and usage and accepted the risk of the memory leak as part of incorrect usage.

[Rookfighter]

Additional note: This library is actually 10 years old now (wow time is running fast!), but I never really had to do any maintenance regarding C++ standard updates (incompatible or missing functionality, etc.). This is the kind of maintenance effort I mean 👍

[abin-z]

First of all, thank you very much for your reply!

I see, what you said makes sense. Using inheritance can indeed easily obtain member functions of std::map, and can also be dynamically updated as the standard library is updated (easy to maintain).
From the above perspective, this is really great. Similarly, almost no one would use it in this way if there is a memory leak (it's just too strange)

As a beginner in C++, I may be influenced by "Effective C++", which has two rules:

• Item 32: Make sure your public inheritance models "is-a" relationship.
• Item 38: Model "has-a" or "is-implemented-in-terms-of" through composition.

From the rules of this book, you should indeed use composition (recommended) or private inheritance (which also needs to expose the corresponding interface).

I am not arguing about right or wrong, but just expressing some of my understanding. This kind of communication is meaningful to me.
I learned a lot from your open source library, especially the implementation of the convert class. Very good.

---

首先, 非常感谢您的回复!

原来如此, 你说的很有道理，使用继承确实能很方便的获取std::map的成员函数, 也能动态的随着标准库的更新而更新(方便维护),
从以上角度看这么做确实很棒. 同样出现内存泄漏的用法几乎不会有人这么用(简直太奇怪)

我做为一个c++的初学者, 可能我是被《Effective C++》所影响了，里面有两条规则：

• 条款32: 确定的你的public继承表现出"is-a"关系
• 条款38: 通过复合表现出"has-a"或者"根据某物实现出"

如果从这本书的规则来看, 确实应该使用复合(推荐)或者是private继承(也是需要暴露对于的接口).

我不是争论对与错, 只是表达我的一些理解. 这种交流对我来说是有意义的.
我从您的开源库中学到了很多东西, 尤其是convert类的实现. 很不错.