Re: [boost] [pimpl] Proposal. Determining interest.

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

Marc,

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.

Best,
Vladimir.

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
>
>