Pimpl idiom

[Simon Hausmann]

On Monday 13 February 2006 09:40, Marc Mutz wrote:
> <snip>
>
> > Attached a proposal for a different implementation of the Pimpl idiom,
> > which has not above problems.
> >
> > It automatically creates on construction, and deletes on destruction the
> > private implementation object, it also propagates the constness to the
> > private object.
> > It is pure C++ and needs no macros or static variables.
>
> <snip>
>
> Yes, and since it uses no macros, it doesn't support the
>   Derived::Private : public Base::Private
> optimization found in Qt4... I've been through three iterations of a
> KDAB::pimpl_ptr of mine, as well as - just now, actually - through the
> implementation of boost::pimpl_ptr (pending boost review atm), and none of
> these make it any more easy to implement Derived than a pale pointer
> (meaning you still need about the same amount of macros as before. I e.g.
> use a macro to generate the ctors and dtors, too, so delete pimpl can't be
> forgotten).
>
> OTOH, there's Q_D and Q_Q and all the declaration macros, and as much as I
> despise them for requiring an extra line of code in _every_ member
> function, they are there, and obviously work (Q_D and Q_Q could be made to
> go away by saying #define d d_func() #define q q_func() in the .cpp file,
> which is what I use in KDAB projects. It prevents you from having a
> variable or parameter 'd' or 'q', but the use of a naked 'd'-pointer
> together with a parameter 'd' triggers what others so fondly call -Wmarc
> anyway (-Wshadow for gcc), so it isn't much of a problem in practice).

The problem with #define d d_func() and q q_func() is that it utterly confuses 
the debuggers. That is why we introduced Q_D/Q_Q.

> Using Q_* macros also makes it easier to derive from QObjectPrivate. The
> only price we had to pay for that would be to have to recomplile kdelibs
> when Qt is changed. Shrug. Has anyone ever used this? Maybe. Has it ever
> worked reliably? Only after explicit fixing in kdelibs.

We can't use QObjectPrivate in KDE, it's not an exported class. And that's 
good :)


Simon