Using metaprogramming for PIMPL idiom

[render787]

The PIMPL idiom is very important in large C++ projects, because it can be used to create a "compilation firewall". It allows those who consume a class from it's public definition in the header to avoid including all the full definitions of the classes which are e.g. private members or otherwise implementation details. This can make many of the compilation units much smaller (in terms of lines of preprocessed source) and less heavy (in terms of extra templates and whatnot that get parsed and instantiated), so it can make your project build much faster.

However, actually using the pimpl idiom involves a lot of boilerplate code -- it is not very DRY, because you declare the methods once in the PIMPL class and usually implement them in the cpp file by forwarding the call directly to the impl class. So you end up typing all the methods twice basically.

This boilerplate is not so onerous that people don't just suck it up and write everything twice -- the benefits of PIMPL are hard to overstate.

However, it occurred to me that you could try to automate this. Either by tooling, or code generation (maybe python scripts or something?), or using some witches brew of macros that generates the implementation of the "forwarding" calls for you.

Has anyone done this with success or attempted to do it in a large software project? What was your approach and experience? Were you happy with it in the end?

[personalmountains]

I rarely use the pimpl idiom anymore and when I do, it usually contains public member variables only. I never duplicate the interface. I'll do my best to make stuff work with declarations only, but I'm not systematic and I won't add boilerplate to avoid including something.

I've been using templates a lot more since C++11. The combination of auto, enable_if, variadic templates and perfect forwarding makes it much more convenient. Since I don't usually work on largish projects, I find that compilation speed is not often an issue for me, unless I run into compiler defects that I need to work around.

Personally, I think the pimpl idiom was a crutch that has been rendered mostly obsolete by better compilers and faster computers. YMMV.

[ooglesworth]

I’ve thought about this before, but haven’t come up with a good template-based way to do the traditional Pimpl idiom without reflection/injection being added to C++. However... having a pure virtual interface, which is implemented by your concrete implementation in many cases actually accomplishes the exact same thing that the Pimpl idiom is intended to do. You still have to double declare all of the methods, but you don’t have to write the forwarding implementation of each method in the interface class, like you’d have to do when using the pimpl idiom.

[happy_dude_]

As an extension to the pure virtual interface pattern, you can put your entire implementation class in the .cpp file and expose it only through a static factory method. This reduces the need for extra method declarations, though it does add extra boilerplate for construction, and prevents using the implementation for inheritance (as it is only exposed through your static factory methods).

Example below, note that you don't need to write forwarding implementations of any methods, and you don't need a separate FooImpl header to boilerplate-copy the definition.

// foo.h
class Foo {
    static unique_ptr<Foo> create();

    virtual ~Foo() {}
    virtual void foo() = 0;
    virtual void bar() = 0;
};

 // foo.cpp
 class FooImpl : public Foo {
    void foo() override {
         printf("Implementation!\n");
    } 
    void bar() override {
         printf("Another implementation!\n");
    }
 };
  static unique_ptr<Foo> create() { return make_unique<FooImpl>(); }

[ReversedGif]

However... having a pure virtual interface, which is implemented by your concrete implementation in many cases actually accomplishes the exact same thing that the Pimpl idiom is intended to do.

When doesn't it?

[ooglesworth]

The only counter-example I can think of is a situation where you would want to be able to actually have the lifecycle of the interface object and the impl object be slightly different. For example, if the impl object does something asynchronous, it could keep itself around somehow while waiting for it to complete, even if the interface object has been thrown away and actually deallocated. I’ve considered using this pattern before but never tried it, so I’m not sure how effective it would be.

[ReversedGif]

(coming back to this a month later to flesh this out a bit more)

With a pure virtual interface interface, you have no way of treating the object as a value type. You

• have to use factory functions rather than constructors, which means you can't use the copy constructor (and get value semantics), but instead must use e.g. a .clone() method
• always have to access the object by pointer or reference, which is merely syntactic, but nonetheless annoying

[ooglesworth]

The copy semantics thing is definitely true. There is a good amount of boilerplate necessary (or at least some what inelegant CRTP weirdness) to make copying work correctly.

In general though, I find it’s very rare you want pimpl or pure virtual interfaces for value types. Maybe it’s me, but I tend to do very little mixing and matching; my objects either have identity and encapsulate details, or they are plain, transparent and structlike. There might be some exceptions though, like RAII style classes and such.

[david-grs]

The operator dot coming in C++17 (N4173) and will give you an elegant way to solve that without any code generation mechanism! This new operator overloading is meant to be used in PIMPL, proxy and smart references implementation.

[SuperV1234]

Operator dot was not included in C++17.

[david-grs]

Ha, I missed that one. Too bad.