Now the unnecessary headers have been removed, and avoidable dependencies on the internals of the class have been eliminated. Is there any further decoupling that can be done? The answer takes us back to basic principles of solid class design.

 

Problem

JG Question

1. What is the tightest coupling you can express in C++? And what’s the second-tightest?

Guru Question

2. The Incredible Shrinking Header has now been greatly trimmed, but there may still be ways to reduce the dependencies further. What further #includes could be removed if we made further changes to X, and how?

This time, you may make any changes at all to X as long as they don’t change its public interface, so that existing code that uses X is unaffected. Again, note that the comments are important.

//  x.h: after converting to use a Pimpl to hide implementation details
//
#include <iosfwd>
#include <memory>
#include "a.h"  // class A (has virtual functions)
#include "b.h"  // class B (has no virtual functions)
class C;
class E;

class X : public A, private B {
public:
       X( const C& );
    B  f( int, char* );
    C  f( int, C );
    C& g( B );
    E  h( E );
    virtual std::ostream& print( std::ostream& ) const;

private:
    struct impl;
    std::unique_ptr<impl> pimpl;   // ptr to a forward-declared class
};

std::ostream& operator<<( std::ostream& os, const X& x ) {
    return x.print(os);
}

 

Solution

1. What is the tightest coupling you can express in C++? And what’s the second-tightest?

Friendship and inheritance, respectively.

A friend of a class has access to everything in that class, including all of its private data and functions, and so the code in a friend depends on every detail of the type. Now that’s a close friend!

A class derived from a class Base has access to public and protected members in Base, and depends on the size and layout of Base because it contains a Base subobject. Further, the inheritance relationship means that a derived type is at least by default substitutable for its Base; whether the inheritance is public or nonpublic only changes what other code can see and make use of the substitutability. That’s pretty tight coupling, second only to friendship.

 

2. What further #includes could be removed if we made further changes to X, and how?

Many programmers still seem to march to the “It isn’t OO unless you inherit!” battle hymn, by which I mean that they use inheritance more than necessary. I’ll save the whole lecture for another time, but my bottom line is simply that inheritance (including but not limited to IS-A) is a much stronger relationship than HAS-A or USES-A. When it comes to managing dependencies, therefore, you should always prefer composition/membership over inheritance wherever possible. To paraphrase Einstein: ‘Use as strong a relationship as necessary, but no stronger.’

In this code, X is derived publicly from A and privately from B. Recall that public inheritance should always model IS-A and satisfy the Liskov Substitutability Principle (LSP). In this case X IS-A A and there’s naught wrong with it, so we’ll leave that as it is.

But did you notice the curious thing about B‘s virtual functions?

“What?” you might say. “B has no virtual functions.”

Right. That is the curious thing.

B is a private base class of X. Normally, the only reason you would choose private inheritance over composition/membership is to gain access to protected members—which most of the time means “to override a virtual function.” (There are a few other rare and obscure reasons to inherit, but they’re, well, rare and obscure.) Otherwise you wouldn’t choose inheritance, because it’s almost the tightest coupling you can express in C++, second only to friendship.

We are given that B has no virtual functions, so there’s probably no reason to prefer the stronger relationship of inheritance—unless X needs access to some protected function or data in B, of course, but for now I’ll assume that this is not the case. So, instead of having a base subobject of type B, X probably ought to have simply a member object of type B. Therefore, the way to further simplify the header is:

 

(a) Remove unnecessary inheritance from class B.

#include "b.h"  // class B (has no virtual functions)

Because the B member object should be private (it is, after all, an implementation detail), and in order to get rid of the b.h header entirely, this member should live in X‘s hidden pimpl portion.

Guideline: Never inherit when composition is sufficient.

 

This leaves us with header code that’s vastly simplified from where we started in GotW #7a:

//  x.h: after removing unnecessary inheritance
//
#include <iosfwd>
#include <memory>
#include "a.h"  // class A (has virtual functions)
class B;
class C;
class E;

class X : public A {
public:
       X( const C& );
    B  f( int, char* );
    C  f( int, C );
    C& g( B );
    E  h( E );
    virtual std::ostream& print( std::ostream& ) const;

private:
    struct impl;
    std::unique_ptr<impl> pimpl;   // this now quietly includes a B
};

std::ostream& operator<<( std::ostream& os, const X& x ) {
    return x.print(os);
}

 

After three passes of progressively greater simplification, the final result is that x.h is still using other class names all over the place, but clients of X need only pay for three #includes: a.h, memory, and iosfwd. What an improvement over the original!

 

Acknowledgments

Thanks in particular to the following for their feedback to improve this article: juanchopanza, anicolaescu, Bert Rodiers.

Now the unnecessary headers have been removed, and avoidable dependencies on the internals of the class have been eliminated. Is there any further decoupling that can be done? The answer takes us back to basic principles of solid class design.

 

Problem

JG Question

1. What is the tightest coupling you can express in C++? And what’s the second-tightest?

Guru Question

2. The Incredible Shrinking Header has now been greatly trimmed, but there may still be ways to reduce the dependencies further. What further #includes could be removed if we made further changes to X, and how?

This time, you may make any changes at all to X as long as they don’t change its public interface, so that existing code that uses X is unaffected. Again, note that the comments are important.

//  x.h: after converting to use a Pimpl to hide implementation details
//
#include <iosfwd>
#include <memory>
#include "a.h"  // class A (has virtual functions)
#include "b.h"  // class B (has no virtual functions)
class C;
class E;

class X : public A, private B {
public:
       X( const C& );
    B  f( int, char* );
    C  f( int, C );
    C& g( B );
    E  h( E );
    virtual std::ostream& print( std::ostream& ) const;

private:
    struct impl;
    std::unique_ptr<impl> pimpl;   // ptr to a forward-declared class
};

std::ostream& operator<<( std::ostream& os, const X& x ) {
    return x.print(os);
}

Now that the unnecessary headers have been removed, it’s time for Phase 2: How can you limit dependencies on the internals of a class?

 

Problem

JG Questions

1. What does private mean for a class member in C++?

2. Why does changing the private members of a type cause a recompilation?

Guru Question

3. Below is how the header from the previous Item looks after the initial cleanup pass. What further #includes could be removed if we made some suitable changes, and how?

This time, you may make changes to X as long as X‘s base classes and its public interface remain unchanged; any current code that already uses X should not be affected beyond requiring a simple recompilation.

//  x.h: sans gratuitous headers
//
#include <iosfwd>
#include <list>

// None of A, B, C, or D are templates.
// Only A and C have virtual functions.
#include "a.h"  // class A
#include "b.h"  // class B
#include "c.h"  // class C
#include "d.h"  // class D
class E;

class X : public A, private B {
public:
       X( const C& );
    B  f( int, char* );
    C  f( int, C );
    C& g( B );
    E  h( E );
    virtual std::ostream& print( std::ostream& ) const;

  private:
    std::list<C> clist;
    D            d;
};

std::ostream& operator<<( std::ostream& os, const X& x ) {
    return x.print(os);
}

 

Solution

1. What does private mean for a class member in C++?

It means that outside code cannot access that member. Specifically, it cannot name it or call it.

For example, given this class:

class widget {
public:
    void f() { }
private:
    void f(int) { }
    int i;
};

Outside code cannot use the name of the private members:

 int main() {
    auto w = widget{};
    w.f();               // ok
    w.f(42);             // error, cannot access name "f(int)"
    w.i = 42;            // error, cannot access name "i"
}

 

2. Why does changing the private members of a type cause a recompilation?

Because private data members can change the size of the object, and private member functions participate in overload resolution.

Note that accessibility is still safely enforced: Calling code still doesn’t get to use the private parts of the class. However, the compiler gets to know all about them at all times, including as it compiles the calling code. This does increase build coupling, but it’s for a deliberate reason: C++ has always been designed for efficiency, and a little-appreciated cornerstone of that is that C++ is designed to by default expose a type’s full implementation to the compiler in order to make aggressive optimization easier. It’s one of the fundamental reasons C++ is an efficient language.

 

3. What further #includes could be removed if we made some suitable changes, and how? … any current code that already uses X should not be affected beyond requiring a simple recompilation.

There are a few things we weren’t able to do in the previous problem:

• We had to leave a.h and b.h. We couldn’t get rid of these because X inherits from both A and B, and you always have to have full definitions for base classes so that the compiler can determine X‘s object size, virtual functions, and other fundamentals. (Can you anticipate how to remove one of these? Think about it: Which one can you remove, and why/how? The answer will come shortly.)
• We had to leave list, c.h and d.h. We couldn’t get rid of these right away because a list<C> and a D appear as private data members of X. Although C appears as neither a base class nor a member, it is being used to instantiate the list member, and some have compilers required that when you instantiate list<C> you be able to see the definition of C. (The standard doesn’t require a definition here, though, so even if the compiler you are currently using has this restriction, you can expect the restriction to go away over time.)

Now let’s talk about the beauty of Pimpls.

 

The Pimpl Idiom

C++ lets us easily encapsulate the private parts of a class from unauthorized access. Unfortunately, because of the header file approach inherited from C, it can take a little more work to encapsulate dependencies on a class’ privates.

“But,” you say, “the whole point of encapsulation is that the client code shouldn’t have to know or care about a class’ private implementation details, right?” Right, and in C++ the client code doesn’t need to know or care about access to a class’ privates (because unless it’s a friend it isn’t allowed any), but because the privates are visible in the header the client code does have to depend upon any types they mention. This coupling between the caller and the class’s internal details creates dependencies on both (re)compilation and binary layout.

How can we better insulate clients from a class’ private implementation details? One good way is to use a special form of the handle/body idiom, popularly called the Pimpl Idiom because of the intentionally pronounceable pimpl pointer, as a compilation firewall.

A Pimpl is just an opaque pointer (a pointer to a forward-declared, but undefined, helper class) used to hide the private members of a class. That is, instead of writing this:

// file widget.h
//
class widget {
    // public and protected members
private:
    // private members; whenever these change,
    // all client code must be recompiled
};

We write instead:

// file widget.h
//
#include <memory>

class widget {
public:
    widget();
    ~widget();
    // public and protected members
private:
    struct impl;
    std::unique_ptr<impl> pimpl;   // ptr to a forward-declared class
};

// file widget.cpp
//
#include "widget.h"

struct widget::impl {
    // private members; fully hidden, can be
    // changed at will without recompiling clients
};

widget::widget() : pimpl{ make_unique<widget::impl>(/*...*/) } { }
widget::~widget() =default;

Every widget object dynamically allocates its impl object. If you think of an object as a physical block, we’ve essentially lopped off a large chunk of the block and in its place left only “a little bump on the side”—the opaque pointer, or Pimpl. If copy and move are appropriate for your type, write those four operations to perform a deep copy that clones the impl state.

The major advantages of this idiom come from the fact that it breaks the caller’s dependency on the private details, including breaking both compile-time dependencies and binary dependencies:

• Types mentioned only in a class’ implementation need no longer be defined for client code, which can eliminate extra #includes and improve compile speeds.
• A class’ implementation can be changed—that is, private members can be freely added or removed—without recompiling client code. This is a useful technique for providing ABI-safety or binary compatibility, so that the client code is not dependent on the exact layout of the object.

The major costs of this idiom are in performance:

• Each construction/destruction must allocate/deallocate memory.
• Each access of a hidden member can require at least one extra indirection. (If the hidden member being accessed itself uses a back pointer to call a function in the visible class, there will be multiple indirections, but is usually easy to avoid needing a back pointer.)

And of course we’re replacing any removed headers with the <memory> header.

We’ll come back to these and other Pimpl issues in GotW #24. For now, in our example, there were three headers whose definitions were needed simply because they appeared as private members of X. If we instead restructure X to use a Pimpl, we can immediately make several further simplifications:

#include <list>
#include "c.h"  // class C
#include "d.h"  // class D

One of these headers (c.h) can be replaced with a forward declaration because C is still being mentioned elsewhere as a parameter or return type, and the other two (list and d.h) can disappear completely.

Guideline: For widely-included classes whose implementations may change, or to provide ABI-safety or binary compatibility, consider using the compiler-firewall idiom (Pimpl Idiom) to hide implementation details. Use an opaque pointer (a pointer to a declared but undefined class) declared as struct impl; std::unique_ptr<impl> pimpl; to store private nonvirtual members.

 

Note: We can’t tell from the original code by itself whether or not X had (default) copy or move operations. If it did, then to preserve that we would need to write them again ourselves since the move-only unique_ptr member suppresses the implicit generation of copy construction and copy assignment, and the user-declared destructor suppresses the implicit generation of move construction and move assignment. If we do need to write them by hand, the move constructor and move assignment can be =defaulted, and the copy constructor and copy assignment will need to copy the Pimpl object.

After making that additional change, the header looks like this:

//  x.h: after converting to use a Pimpl
//
#include <iosfwd>
#include <memory>
#include "a.h"  // class A (has virtual functions)
#include "b.h"  // class B (has no virtual functions)
class C;
class E;

class X : public A, private B {
public:
    ~X();                          // defined out of line
    // and copy/move operations if X had them before

       X( const C& );
    B  f( int, char* );
    C  f( int, C );
    C& g( B );
    E  h( E );
    virtual std::ostream& print( std::ostream& ) const;

private:
    struct impl;
    std::unique_ptr<impl> pimpl;   // ptr to a forward-declared class
};

std::ostream& operator<<( std::ostream& os, const X& x ) {
    return x.print(os);
}

Without more extensive changes, we still need the definitions for A and B because they are base classes, and we have to know at least their sizes in order to define the derived class X.

The private details go into X‘s implementation file where client code never sees them and therefore never depends upon them:

//  Implementation file x.cpp
//
#include <list>
#include "c.h"  // class C
#include "d.h"  // class D
using namespace std;

struct X::impl {
    list<C> clist;
    D       d;
};

X::X() : pimpl{ make_unique<X::impl>(/*...*/) } { }
X::~X() =default;

That brings us down to including only four headers, which is a great improvement—but it turns out that there is still a little more we could do, if only we were allowed to change the structure of X more extensively. This leads us nicely into Part 3…

 

Acknowledgments

Thanks to the following for their feedback to improve this article: John Humphrey, thokra, Motti Lanzkron, Marcelo Pinto.

Google’s doodle today reminded me of Grace Hopper’s amazing contributions.

I enjoyed this 10-minute video, and you might as well: Grace Hopper on Letterman in 1986 on the occasion of her (final) retirement.

It’s not deep, but especially in the second half Amazing Grace demonstrates how to talk to a non-specialist audience. Good reminders for all of us who speak Geek Jargon a little too fluently!

We just shipped Visual C++2013 last month, but I announced at GoingNative in September that there would be more soon: another CTP (compiler preview) containing another batch of C++11/14 features, sometime in the fourth quarter.

I’m happy to report that today we shipped the promised CTP. Compared to the “high probability in CTP” feature set I mentioned in my GoingNative talk, one of those features I mentioned didn’t quite make it (C++14 generalized lambda capture, a.k.a. move capture and more), but to compensate, both medium-probability features made it (C++14 generic lambdas and C++11 inheriting constructors) plus, as a bonus, also alignof and alignas which we didn’t think would make it for the CTP but did. Here’s the full set of new features, pasting from the announcement:

• Implicit move special member function generation (thus also completing =default)
• Reference qualifiers on member functions (a.k.a. “& and && for *this“)
• Thread-safe function local static initialization (a.k.a. “magic statics”)
• Inheriting constructors
• alignof/alignas
• __func__
• Extended sizeof
• constexpr (except for member functions)
• noexcept (unconditional)
• C++14 decltype(auto)
• C++14 auto function return type deduction
• C++14 generic lambdas (with explicit lambda capture list)
• (Proposed for C++17) Resumable functions and await

The most-requested feature of C++14, and the one I’ve personally been anticipating the most, is generic lambdas — it is sweet to see it working right within Visual Studio 2013, as the CTP installs as a selectable toolset you can use within the shipping product to edit and build (no Intellisense or red squiggles though). Note that for this CTP, your lambda can be either generic (have an auto parameter type) or have a default capture list (e.g., [=] or [&]), but not both — of course we’ll support both together in the future as the feature makes a future release.

As far as I know, this Visual C++ CTP is the first shipping (albeit CTP quality) C++ compiler to offer generic lambdas, though I expect Clang and gcc to also make them available soon — joy for C++ developers everywhere!

Once again, thank you very much again to the great Visual C++ team for producing this CTP; even as we speak, they’re hard at work on more. Thanks again also to the other members of the ISO C++ committee for producing a great and high-quality C++11 and soon-to-be-not-draft C++14.

I hope you enjoy trying out this CTP.

As part of today’s VS 2013 launch, in addition to the live talks and Q&A we also have some recently recorded talks that are now also live. My talk is a quick 20-minute tour of the new ISO C++ conformance features in VC++ 2013 — nothing I haven’t said before, so if you’ve seen my last two Build talks you’ve seen this material, only here I’ve condensed it to a distilled two-minute overview of each feature using examples.

Here they are, each between 4 and 20 minutes long. Note that these are just the (V)C++-specific topics — be sure to look at the Related Videos of each to see other new features that light up for C++ as well as for other languages.

ISO C++ Additions in Visual C++ 2013 (Herb Sutter)

ISO C++ received a major upgrade with the latest standard, adding many features that make the language both simpler and more powerful. Visual C++ 2010 and 2012 have already implemented a number of these features, from auto to range-for to lambdas.  In this video, Herb Sutter reviews the additional ISO C++ standards conformance improvements in Visual C++ 2013, and how each of them contributes to making modern C++ code clean, safe, and faster than ever.

​What’s New for C++ Developers in Visual Studio 2013 IDE​ (Jennifer Leaf)

Visual Studio 2013 includes several compelling new features for C++ developers.  In this video, you’ll learn about IntelliSense improvements, the new code formatting feature, and other changes that help you navigate through and write your code.

New Compiler Optimizations for C++ Applications (Jim Hogg & Ankit Asthana)

C++ developers will find many improvements in Visual Studio 2013 — including new versions of the compiler, linker and tools — that make code run faster.  In this video we’ll cover C++ performance improvements, including better vectorization; permutation in the order of loop nests; better Profile-Guided Optimization (that now applies to Windows Store apps); a new vector calling convention; and more support for C++ Accelerated Massive Parallelism (AMP).

Debugging Improvements for C++ Developers (Brad Sullivan)

Visual Studio 2013 includes numerous improvements for debugging C++ applications.  In this video we’ll demo two of these features: Just My Code and JavaScript/Native Interop Debugging.

Introducing Visual Studio 2013 for Windows Developers Building C++ Apps (Raman Sharma)

Visual C++ in Visual Studio 2013 includes improvements for Windows App developers in the core language and libraries, as well in tooling, debugging and designers.  This video will provide an overview of these new features in Visual Studio 2013 for C++ developers building Windows Store apps.

As part of the VS 2013 launch today, in a few hours I will be joining Tarek Madkour and Ale Contenti on camera for about half an hour to answer questions about VC++2013. Tarek and Ale are two of the three-manager triad who run our VC++ team.

Visual C++ in 2013 and Beyond

with Charles Torre, Ale Contenti, Tarek Madkour, and Herb Sutter

Date: November 13, 2013
Time: 12:45pm PST (approx.)

I believe the session will be recorded and available on demand in a couple of days.

Recap: Back in June, Microsoft:

• announced that were were moving to a faster cadence and shipped VS 2013 one year after VS 2012;
• announced that new ISO C++ conformance features from the November 2012 CTP (and more) would be available in VS 2013, but not in VS 2012 Updates; and
• didn’t announce pricing for VS 2013, so people who had just paid for VS 2012 Professional (only that specific SKU) were concerned that they might be charged full price again for VS 2013 Professional. (This applies to Professional only, because all other SKUs get free upgrades anyway — Express is always free, and Premium and Ultimate are subscription-based with free upgrades included in the subscription.)

I just want to remind anyone who bought VS 2012 Professional that when the actual pricing was announced last month, it was announced that to ease the transition there would be a limited time promotional upgrade from VS 2012 Professional to VS 2013 Professional for $99, available from early November (now) until the end of January. You can wait until after the holidays to decide whether you want it, but I thought I’d just give another heads-up about the time limit if this upgrade matters to you.

I hope this is a good value, as VS 2013 has lots of new features for C++ users beyond just the additional ISO C++ conformance: lots of editor improvements from simple things like brace completion and parameter-sensitive Intellisense to the (IMO cool) enhanced scrollbar and peek definition; C++ AMP improvements; optimization improvements including a smarter auto-vectorizer; and much more. See this blog post for an overview of what’s new in VC++ 2013 — the team did a lot in just one year, and thank you again to everyone who helped to make this happen!

What’s next for Visual C++:

• At Build and GoingNative, we announced that a preview CTP of the next batch of C++11/14 language features will be available this quarter. We’re still on track for that. Watch vcblog and this space for the announcement.
• Tomorrow is the VS 2013 virtual launch. Given that we already shipped the product itself a month ago so that you already have it in your hands, is there any reason to watch the launch? Short answer: Yes, I think you’ll find it interesting and worth your while.

I just posted my trip report on isocpp.org. Also be sure to read the Current ISO C++ status page.

We accomplished a lot last week — thanks to all the volunteers for making this a very productive and successful meeting!

Just to visualize everything that’s going on, here’s a copy of the current ISO C++ timeline… enjoy.