Boost logo

Boost :

From: Marc Mutz (marc_at_[hidden])
Date: 2007-11-02 09:55:38

On Thursday 01 November 2007 20:12, Vladimir.Batov_at_[hidden] wrote:
> It has to be remembered that Pimpl idiom is about implementation hiding,
> i.e. it's about implementation and it's about hiding. It's not about
> making a class to behave as a pointer -- that is done by shared_ptr and
> done beautifully. A Pimpl-based class is by all means an ordinary class.
> The fact that its implementation is done in pimpl fashion is an
> implementation detail and is irrelevant when one inherits from that class.

I respectfully disagree.

If you have a class library with a fairly deep class hierarchy, re-using the
pimpl_ptr from a base class (and inheriting Private classes from each other),
is a very valid optimization, both in time and space. Taking Qt (KDE has of
course a very similar technique) as an example, we have
  QTextBrowser -> QTextEdit -> QAbstractScrollArea -> QWidget -> QObject
All of which are pimpl'ed for binary compatibility reasons. Unless you can
inherit QTextBrowserPrivate from QTextEditPrivate, and stuff it into
QObject::pimpl, there's a space overhead (4*sizeof(void*)) + a memory
management overhead that could (and should) be avoided. Implementation hiding
in this case means hiding from the user of the library, not from other
components of the library.

Doing this also helps establishing 'module' access rights, otherwise lacking
in C++, but useful for scaling to very large systems. E.g., I could make
members of QObjectPrivate virtual, and therefore provide protected extension
vectors that are only accessible from the 'module', ie. from within the same

Any pimpl_ptr proposal that does not adequately deal with this (common, in my
line of work) scenario wouldn't meet my personal generality requirements.


Marc Mutz -- marc_at_[hidden], mutz_at_[hidden]
Klarälvdalens Datakonsult AB, Platform-independent software solutions

Boost list run by bdawes at, gregod at, cpdaniel at, john at