![\"hierarchy](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/hierarchy-35795_1280.png\")
<\/p>\nDue to the C++ core guidelines, “Templates are the backbone of C++\u2019s support for generic programming and class hierarchies the backbone of its support for object-oriented programming. The two language mechanisms can be combined effectively, but a few design pitfalls must be avoided.” Let me see what this means.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
This section consists of five rules.<\/p>\n
Rule T.81 is too loosely related to templates and hierarchies, and rule T.82 is empty; therefore, my post boils down to the three remaining rules.<\/p>\n
I will write about the rules T.80 and T.84 together because T.84 continues the story of T.80.<\/p>\n<\/p>\n
<\/p>\n
Here is an example a naively templatized class hierarchy from the guidelines:<\/p>\n
<\/p>\n
template<\/span><<\/span>typename<\/span> T><\/span>\r\nstruct<\/span> Container { \/\/ an interface<\/span>\r\n virtual<\/span> T*<\/span> get(int<\/span> i);\r\n virtual<\/span> T*<\/span> first<\/span>();\r\n virtual<\/span> T*<\/span> next<\/span>();\r\n virtual<\/span> void<\/span> sort<\/span>();\r\n};\r\n\r\ntemplate<\/span><<\/span>typename<\/span> T><\/span>\r\nclass<\/span> Vector<\/span> :<\/span> public<\/span> Container<<\/span>T><\/span> {\r\npublic:<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n\r\nVector<<\/span>int<\/span>><\/span> vi;\r\nVector<<\/span>string><\/span> vs;\r\n<\/pre>\n<\/div>\n <\/p>\n
Why is this due to the guidelines naively? This is, in particular, naively because the base class Container<\/span> has many virtual functions. The presented design introduces code bloat. Virtual functions are instantiated every time in a class template. In contrast, non-virtual functions are only instantiated if they are used.<\/p>\nA simple test with CppInsight<\/a> proves my point.<\/p>\nNon-virtual functions<\/h3>\n
The program uses a std::vector<int><\/span> and a std::vector<std::string><\/span>.<\/p>\n![\"Vector1\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/Vector1.png\")
<\/p>\n
CppInsight shows it. No method of std::vector<\/span> is instantiated.<\/p>\n![\"Vector2\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/Vector2.png\")
<\/p>\n
Virtual functions<\/h3>\n
Here is the simplified program of the C++ core guidelines, including the virtual function sort.<\/span><\/p>\n![\"Vector1Virtual\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/Vector1Virtual.png\")
<\/p>\n
Now, the virtual function sort<\/span> is instantiated. Here is only the output of CppInsight, which shows the instantiation of the class template Container. <\/span><\/p>\n![\"Vector2Virtual\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/Vector2Virtual.png\")
<\/p>\n
<\/p>\n
In total, I get 100 lines of code for the virtual function.<\/p>\n
The note to the guidelines hints at how to overcome this code bloat. Often you can provide a stable interface by not parameterizing a base. This brings me to the related rule T.84: Use a non-template core implementation to provide an ABI-stable interface<\/a>.<\/p>\nOkay, I already have written about this technique in the post C++ Core Guidelines: Template Definitions<\/a>. Rule T.84 mentions an alternative way to address a stable interface: Pimpl. <\/a><\/p>\nPimpl<\/h3>\n
Pimpl stands for “p<\/strong>ointer to impl<\/strong>ementation” and means to remove implementation details of a class by placing them in a separate class, accessed through a pointer. This technique should be in the toolbox of each serious C++ programmer. Pimpl is often also called a compilation firewall because this technique breaks the dependency between the implementation and the users of the class interface. This means the implementation can be changed without recompiling the user code.<\/p>\nHere is the general structure from Herb Sutters Blog: GotW #100<\/a>: Compilation Firewalls. <\/span><\/p>\n <\/p>\n
\n\/\/ in header file<\/span>\r\nclass<\/span> widget<\/span> {\r\npublic:<\/span>\r\n widget();\r\n ~<\/span>widget();\r\nprivate:<\/span>\r\n class<\/span> impl<\/span>; \/\/ (1)<\/span>\r\n unique_ptr<<\/span>impl><\/span> pimpl;\r\n};\r\n \r\n\/\/ in implementation file \/\/ (2) <\/span>\r\nclass<\/span> widget<\/span>::<\/span>impl {\r\n \/\/ :::<\/span>\r\n};\r\n \r\nwidget::<\/span>widget() :<\/span> pimpl{ new<\/span> impl{ \/*...*\/<\/span> } } { }\r\nwidget::~<\/span>widget() { } \r\n<\/pre>\n<\/div>\n <\/p>\n
These are the points of this idiom.<\/code><\/p>\n\n- put all private non-virtual members into impl<\/span> (1)<\/li>\n
- forward declare impl
<\/span><\/li>\n- define impl<\/span> in the corresponding implementation file (2)
<\/code><\/li>\n<\/ol>\nOkay. Let me show a full example based on the one from cppreference.com<\/a>.<\/p>\n <\/p>\n
\n\/\/ pimpl.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <memory><\/span>\r\n \r\n\/\/ interface (widget.h)<\/span>\r\nclass<\/span> widget<\/span> {\r\n class<\/span> impl<\/span>;\r\n std::<\/span>unique_ptr<<\/span>impl><\/span> pImpl;\r\n public:<\/span>\r\n void<\/span> draw<\/span>();\r\n bool<\/span> shown() const<\/span> { return<\/span> true<\/span>; } \r\n widget(int<\/span>);\r\n ~<\/span>widget(); \r\n widget(widget&&<\/span>) =<\/span> default<\/span>; \r\n widget(const<\/span> widget&<\/span>) =<\/span> delete<\/span>;\r\n widget&<\/span> operator<\/span>=<\/span>(widget&&<\/span>); \r\n widget&<\/span> operator<\/span>=<\/span>(const<\/span> widget&<\/span>) =<\/span> delete<\/span>;\r\n};\r\n \r\n\/\/ implementation (widget.cpp)<\/span>\r\nclass<\/span> widget<\/span>::<\/span>impl {\r\n int<\/span> n; \/\/ private data<\/span>\r\n public:<\/span>\r\n void<\/span> draw<\/span>(const<\/span> widget&<\/span> w) { \/\/ (1)<\/span>\r\n if<\/span>(w.shown())\r\n std::<\/span>cout <<<\/span> \"drawing a widget \"<\/span> <<<\/span> n <<<\/span> '\\n'<\/span>;\r\n }\r\n impl(int<\/span> n) :<\/span> n(n) {}\r\n};\r\nvoid<\/span> widget::<\/span>draw() { pImpl-><\/span>draw(*<\/span>this<\/span>); } \/\/ (2)<\/span>\r\nwidget::<\/span>widget(int<\/span> n) :<\/span> pImpl{std::<\/span>make_unique<<\/span>impl><\/span>(n)} {}\r\nwidget::~<\/span>widget() =<\/span> default<\/span>; \/\/ (3)<\/span>\r\nwidget&<\/span> widget::<\/span>operator<\/span>=<\/span>(widget&&<\/span>) =<\/span> default<\/span>;\r\n \r\n\/\/ user (main.cpp)<\/span>\r\nint<\/span> main<\/span>()\r\n{\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\t\r\n widget w(7<\/span>);\r\n w.draw();\r\n\t\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The draw<\/span> call of the class impl<\/span> uses a back-reference to widget<\/span> (lines (1) and (2)). The destructor and the move assignment operator (line (3)) must be user-defined in the implementation file base because std::unique_ptr<\/a><\/span> requires that the pointed-to type is complete.<\/p>\nThe program behaves as expected:<\/p>\n
![\"pimpl\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/pimpl.png\")
<\/p>\n
Besides its pros, the pimpl idiom has two cons: there is an additional pointer indirection, and you have to store the pointer.<\/p>\n
The last guideline for this post is about a typical misconception.<\/p>\n
T.83: Do not declare a member function template virtual<\/a><\/h2>\nLet me try to use a virtual member function template.<\/p>\n
<\/p>\n
\n\/\/ virtualMember.cpp<\/span>\r\n\r\nclass<\/span> Shape<\/span> {\r\n template<\/span><<\/span>class<\/span> T<\/span>><\/span>\r\n virtual<\/span> bool<\/span> intersect(T*<\/span> p);\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n Shape shape;\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The error message from my GCC 8.2 compiler is crystal-clear:<\/p>\n
![\"virtualMember\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/12\/virtualMember.png\")
<\/p>\n
What’s next?<\/h2>\n