From boost Fri Nov 02 11:58:33 2007 From: Marc Mutz Date: Fri, 02 Nov 2007 11:58:33 +0000 To: boost Subject: Re: [boost] [pimpl] Proposal. Determining interest. Message-Id: <200711021355.41756.marc () klaralvdalens-datakonsult ! se> X-MARC-Message: https://marc.info/?l=boost&m=119400471302898 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