Is the PIMPL idiom really used in practice?

by

So, I am wondering it this technique is really used in practice? Should I use it everywhere, or with caution?

Of course it is used. I use it in my project, in almost every class.

Reasons for using the PIMPL idiom:

Binary compatibility

When you’re developing a library, you can add/modify fields to XImpl without breaking the binary compatibility with your client (which would mean crashes!). Since the binary layout of X class doesn’t change when you add new fields to Ximpl class, it is safe to add new functionality to the library in minor versions updates.

Of course, you can also add new public/private non-virtual methods to X/XImpl without breaking the binary compatibility, but that’s on par with the standard header/implementation technique.

Data hiding

If you’re developing a library, especially a proprietary one, it might be desirable not to disclose what other libraries / implementation techniques were used to implement the public interface of your library. Either because of Intellectual Property issues, or because you believe that users might be tempted to take dangerous assumptions about the implementation or just break the encapsulation by using terrible casting tricks. PIMPL solves/mitigates that.

Compilation time

Compilation time is decreased, since only the source (implementation) file of X needs to be rebuilt when you add/remove fields and/or methods to the XImpl class (which maps to adding private fields/methods in the standard technique). In practice, it’s a common operation.

With the standard header/implementation technique (without PIMPL), when you add a new field to X, every client that ever allocates X (either on stack, or on heap) needs to be recompiled, because it must adjust the size of the allocation. Well, every client that doesn’t ever allocate X also need to be recompiled, but it’s just overhead (the resulting code on the client side will be the same).

What is more, with the standard header/implementation separation XClient1.cpp needs to be recompiled even when a private method X::foo() was added to X and X.h changed, even though XClient1.cpp can’t possibly call this method for encapsulation reasons! Like above, it’s pure overhead and is related with how real-life C++ build systems work.

Of course, recompilation is not needed when you just modify the implementation of the methods (because you don’t touch the header), but that’s on par with the standard header/implementation technique.

Is this technique recommended to be used in embedded systems (where the performance is very important)?

That depends on how powerful your target is. However the only answer to this question is: measure and evaluate what you gain and lose. Also, take into consideration that if you’re not publishing a library meant to be used in embedded systems by your clients, only the compilation time advantage applies!

More Related Contents:

  1. Why should the “PIMPL” idiom be used? [duplicate]
  2. C++ I/O File stream advantages over C language
  3. Does the stream operator exist for class member functions?
  4. Weird behavior with OOP and string pointers
  5. When should you use ‘friend’ in C++?
  6. Why are unnamed namespaces used and what are their benefits?
  7. What are the differences between struct and class in C++?
  8. How to use the Qt’s PIMPL idiom?
  9. When should I use C++ private inheritance?
  10. C++ virtual function from constructor [duplicate]
  11. What constitutes a valid state for a “moved from” object in C++11?
  12. What are Mixins (as a concept)
  13. How do you create a static class in C++?
  14. What is the point of a private pure virtual function?
  15. Does the GotW #101 “solution” actually solve anything?
  16. map set/get requests into C++ class/structure changes
  17. How does virtual method invocation work in C++?
  18. Will an ’empty’ constructor or destructor do the same thing as the generated one?
  19. What is the difference between a concrete class and an abstract class?
  20. What is the best way to create a sparse array in C++?
  21. Inheritance or composition: Rely on “is-a” and “has-a”?
  22. Should I use shared_ptr or unique_ptr
  23. Why is the STL so heavily based on templates instead of inheritance?
  24. C++ virtual table layout of MI(multiple inheritance)
  25. C++ inheritance and member function pointers
  26. Object oriented programming in Haskell
  27. C++ Double Dispatch for Equals()
  28. How does the C++ compiler know which implementation of a virtual function to call?
  29. Why should I prefer to use member initializer lists?
  30. Should objects delete themselves in C++?

Leave a Comment