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.
In a word… NO.
Microsoft Word produces typographically ugly documents, and the Office 365 suite consumes many gigabytes of space on your disk, but it’s your choice to use this tool if you like. Just please, please export it to something that works on any platform, like a PDF file.
(…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).
The following transmission is directed toward the (job) recruiting community everywhere. It’s time to get together and improve the way employees and employers connect with each other. The current method of matching software engineering candidates with software engineering jobs is completely broken. With so many good people out there looking for work, and so many good companies out there looking for good people, you’d think this would be no problem — especially in an age of so much technology centered around communication. If you have landed here, that’s a good start. Well, here is what I think are some of the roadblocks in this fundamentally ﬂawed process.