What are the pros and cons of using d-pointers?

Question

d-pointers are heavily used in Qt, they are an implementation of pimpl idiom. I know advantages and disadvantages of pimpl idiom. But I have missed the advantages of d-pointers implementation. Here and here are the samples of d-pointers. Isn't it easier to just use this?

class MyClassPrivate;
class MyClass {
  // interface methods
private:
  MyClassPrivate *pimpl_;
};

Answer 1

The set of macros for d-pointer pattern provides some sort convenience and consistencies. For example, Q_DECLARE_PRIVATE ensures that the pimpl private class for Foo is named as FooPrivate, that FooPrivate befriends Foo, and creates an nice inline function (both const and nonconst versions) called d_func(). The latter is used in Q_D macro, which basically creates a scoped/local variable d which points to the private class instance.

In short, you need not use Q_DECLARE_PRIVATE and other macros, but doing so will make the code shorter, cleaner, and consistent.

Answer 2

I think that d-pointers are really just a few handy macros for implementing the pimpl idiom. Just take a look at the definition of all these macros: Q_D, Q_Q, Q_DECLARE_PRIVATE, etc. They are just shortcuts for parts of pimpl. For example most of the time you want to keep the reference to the original class in the private class. There are Q_Q and Q_DECLARE_PUBLIC for this. After all, using the macros forces all the team to have a uniform implementation of pimpl. Otherwise some people would call the private pointer d, others pimpl_, imagine this mess.

Answer 3

d-pointers are one implementation, among many, of the pimpl pattern. It is also one of the early implementations: "The name 'd-pointer' stems from Trolltech's Arnt Gulbrandsen, who first introduced the technique into Qt, making it one of the first C++ GUI libraries to maintain binary compatibility even between bigger release." Source

One advantage of using macros is the option of changing some implementation details of the pattern implementation in a central place at compile time. You could for example design your macros to leave you the option of switching to the fast pimpl implementation at a later time without changing tons of code (hopefully you won't need this if you are using pimpl :-)). Provided that you made no mistakes in your macro design/implementation...

However, I would personally recommend avoiding macros for your pimpl implementation as they are cryptic for any newcomer to your source tree. Macros create magical dialects that are often error-prone and not as meaningful as the original source code. They also come with all the problems associated with the C Pre Processor; it's unaware of the underlying language.

Personally I like to use what I call a d-reference. Instead of a pointer, you use a reference and you don't have to d-reference. 8-) It looks something like this:

// MyClass.h

class MyClass
{
public:
    MyClass();
    ~MyClass();

    // implementation methods

private:
    class MyClassPrivate& d;
};

// MyClass.cpp

struct MyClassPrivate
{
    int x;
};

MyClass::MyClass()
: d(*new MyClassPrivate)
{

}

MyClass::~MyClass()
{
    delete &d;
}

// In methods use d.x