[Development] d_ptr and q_ptr

Olivier Goffart olivier at woboq.com
Tue Nov 22 08:53:47 CET 2011


On Tuesday 22 November 2011 11:52:44 David Laing wrote:
> Hi all,
> 
> I was just reading this:
>    http://herbsutter.com/gotw/_100/
> and got to wondering about the pimpl idiom in Qt with respect to
> forwards compatibility with C++11.
> 
> Should there be some discussion of the relative merits of using
>    QFooClass* QFooClassPrivate::q_ptr
> to refer to public classes from inside the private implementation
> classes versus using
>    QFooClassPrivate::barMethod(QFooClass *parent, <<bar method args>>)
> for the methods that need to use the parent reference.
> 
> At the moment we tend to use the first technique.  The downside is that
> we would then need to make sure that q_ptr is kept up to date if the
> parent class is acted on by the move operators from C++11.
> 
> This could be remedied by documenting that you need to update the
> pointers after a move and providing examples (preferably including
> examples on how to detect if you have support for the move operators as
> well).  We'd also need to update the existing code if we want to avoid
> surprises there.
> 
> With the second technique we'd avoid the need to update the pointer,
> although we'd still need to document the new idiom and then update the
> existing code.
> 
> There are a few other issues that are also probably relevant (how to
> deal with grandparents, for instance) , but I figured it's worth
> mentioning the basic issue to stimulate some discussion and see what
> falls out.

There is mostly two kinds of objects in Qt.
 - The implicitly shared objects:
     Those ones do not (and cannot) have a q_ptr, since they can be shared.

 - The non copyables objects (such as all the QObjects):
     They are no copyable (Q_DISABLE_COPY), hence, not movable. so there is no
     risks of having the q_ptr out of sync.

I can't recall an example of non-shared copyable class with a private 
implementation in Qt, so that mean they are rares.

In conclusion, I see no reason to change our current ways.
(better not change it if it is not broken)





More information about the Development mailing list