Matthew R. Bisson

When Empty Base Optimization Goes “Wrong”

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

Continue reading “When Empty Base Optimization Goes “Wrong””

An Exploration of the Deleter on the Memory Footprint of std::unique_ptr

(…or “How I Learned to Love the Tuple.”)

Although the C++ standard does not explicitly spell it out, one may hope for a sophisticated implementation of the std::unique_ptr that consumes exactly as much memory as the pointer it tracks when it is configured to use a empty-class deleter (such as the default deleter type). The unique_ptr indeed allows the consumer to supply a custom deleter, which one intuitively expects to consume memory — if you store two pieces of data, you will consume two spots in memory somehow, right? Not quite. I will explore how this is done (specifically in GCC).

Continue reading “An Exploration of the Deleter on the Memory Footprint of std::unique_ptr