Boost logo

Boost :

From: Vladimir Batov (batov_at_[hidden])
Date: 2007-11-02 19:08:29


I have re-read the Bridge pattern in GoF Pattern Bible. Their example is
just what you describe in your example. I agree that having/supporting
two separate hierarchies is an elegant solution to a few problems. Let
me think how pimpl<> might support that.


Marc Mutz wrote:
> 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
> library.
> 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.
> Thanks,
> Marc

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