{"id":129,"date":"2023-02-27T10:30:00","date_gmt":"2023-02-27T15:30:00","guid":{"rendered":"https:\/\/cyberbisson.com\/blog\/?p=129"},"modified":"2023-02-27T10:37:47","modified_gmt":"2023-02-27T15:37:47","slug":"when-empty-base-optimization-goes-wrong","status":"publish","type":"post","link":"https:\/\/cyberbisson.com\/blog\/2023\/02\/27\/when-empty-base-optimization-goes-wrong\/","title":{"rendered":"When Empty Base Optimization Goes \u201cWrong\u201d"},"content":{"rendered":"
\n\n<\/div>\n

Occasionally, we use C++ inheritance to \u201ctag\u201d a class for some later purpose, or perhaps to introduce a functional change without copying code (e.g., boost::noncopyable<\/a><\/tt>). When the inherited class has no data, we (quite reasonably) expect to incur no run-time size overhead, due to Empty Base Optimization<\/a> (EBO), but there is one surprising case where we must take care, or unintentionally waste memory. In this article, let\u2019s explore the issue, and how to guard against it.<\/p>\n

<\/p>\n\n

The Problem<\/h1>\n

When you write a class with nothing in it, it is very surprising to do some compile-time check, and find that objects are paying a penalty for using that empty class. The C++ Standard (C++20; \u00a76.7.2.8) defines what \u201cempty\u201d really means, but it\u2019s generally what you\u2019d expect: if a class has no fields and no virtual functions (ignoring a few other qualifications), you can pretty much expect it to be empty. This means that when one derives from the class, the base should consume zero bytes of space \u2014 EBO \u2014 but there\u2019s a wrinkle (emphasis, mine):<\/p>\n

\n Two objects with overlapping lifetimes [\u2026] may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types;<\/strong> otherwise, they have distinct addresses and occupy disjoint bytes of storage.<\/p><\/blockquote>\n

This verbiage is dense with meaning, but essentially, if one has a zero-length object at the start of a structure, and a zero-length object as the base class, and<\/em> they are the same type, then the compiler must give space to the base class so it has a distinct memory address. Consider an example:<\/p>\n

struct empty_class { };\n\nstruct smaller_class : empty_class {\n    long long int m_x[2];\n};\n\nstruct bigger_class : empty_class {\n    smaller_class m_sc;\n};\n\nstruct biggest_class : empty_class {\n    bigger_class m_bc;\n    smaller_class m_sc;\n};\n<\/pre>\n
First, what are we trying<\/em> to have the sizes of these objects be?  The obvious expectation is:<\/p>\n