mutz at kde.org
Mon Feb 13 08:40:43 GMT 2006
> 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.
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).
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel