Kasun’s Blog

Kasun Indrasiri

  • Calendar

    November 2009
    M T W T F S S
    « Sep   Dec »
  • My Flickr

  • Meta

  • Advertisements
  • Kasun Indrasiri

  • Info

    Department of CSE
    University of Moratuwa,
    Sri Lanka

  • Archives

  • Categories

Crafty ‘Pimpl’ : Compilation Firewall

Posted by kasun04 on November 9, 2009

The Pimpl idiom or ‘Pointer to Implementation’ (aka compilation firewall or Cheshire Cat technique) is a technique of hiding implementation details by moving private members (both data and functions) of a class into an internal private struct (or class). So it simply minimizes coupling via the separation of interface and implementation and then implementation hiding. Therefore pimpl idiom insulates clients from all knowledge about the encapsulated parts of a class.

Although, ‘pimpl’ is a cool technique to achieve ‘pure encapsulation’ and decoupling, it is often used as a compiling time optimization technique. In a non-pimpl scenario, the clients depend on the header file of a class, any changes to the header will affect clients, even if they are made to the private or protected sections. But with pimpl idiom, it hides those private details by putting private data (and functions) in a separate type defined in the implementation file and then forward declaring the type in the header file and storing a pointer to it (pointer to implementation).

Source code sample – here!

‘Pimpl’ : How to do it

This is how we can convert a non-pimpl class to a pimpl. (say FooStr is the main class and Ximpl is the implementation class)

  • Put all the private member variables into a struct/class. (move all private data from FooStr to Ximpl)
  • Define the struct/class in .cpp. (Ximpl definition)
  • Forward declaration of the struct/class in .h (class Ximpl)
  • Declare a pointer to the implementation class as a (smart) pointer (of course as a private attribute) – boost::scoped_ptr<Ximpl> pimpl
  • Instantiate struct/class in the ctor of the main class
  • May be we need to modify the copy ctor and also the destructor (if boost smart ptrs are not used)
  • (please refer to source code for further clarifications)

I know this makes your code looks so ambiguous at first sight, but since this is a standard C++ technique we don’t need to worry about the complexity. Let’s take a look at pros and cons of pimpl.


  • Changing private member variables of a class does not require recompiling the dependent client classes – Faster Compiling time
  • The header file does not need to ‘#include’ classes that are used in private member variables – again compiles faster
  • True and pure ‘Encapsulation’


  • Tough work for the developer (J)
  • Less readable
  • Doesn’t support ‘protected’ member variables


For further information on pimpl, please refer ‘Exceptional C++’.



3 Responses to “Crafty ‘Pimpl’ : Compilation Firewall”

  1. Thanuja said

    It looks good!

  2. Ethan said

    Thank you for the explanation. I’ll start incorporating this in future projects.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: