[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [pimpl] Proposal. Determining interest.
From:       Marc Mutz <marc () klaralvdalens-datakonsult ! se>
Date:       2007-11-02 11:58:33
Message-ID: 200711021355.41756.marc () klaralvdalens-datakonsult ! se
[Download RAW message or body]

On Thursday 01 November 2007 20:12, Vladimir.Batov@wrsa.com.au 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

-- 
Marc Mutz -- marc@klaralvdalens-datakonsult.se, mutz@kde.org
Klarälvdalens Datakonsult AB, Platform-independent software solutions
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[prev in list] [next in list] [prev in thread] [next in thread]