Yes, I meant the "private subclassing" in a way like the one used by Qt
where it's used to both hide internals from the outer world and reduce
memory overhead by sharing one 'd_ptr' field between many classes.
But no, 'd_ptr' must be private to prevent classes derived from
DisplayWidget from chang
Ok, but if your 'private' class is designed to be derived from, then I
guess it was not all that private after all. It is more like it is to be
protected instead of private. If the class really is private (for
instance by not using a displaywidget_p.h for declaring it, but by just
forward-decla
Right, but:
1) classes derived from DisplayWidget may want to derive their *Private
counterparts from DisplayWidgetPrivate — in this case private section
will make DisplayWidgetPrivate's internals accessible only to this class
itself and its friend DisplayWidget;
2) since not all compilers support
Constantin Makshin schreef op 11.11.2013 18:33:
> 1) put your 'd_ptr' into a smart pointer of some kind (usually
> QScopedPointer), your example leaks memory;
> 2) placing 'q_ptr' in the public section doesn't make much sense
> because
> it's supposed to be used only by the DisplayWidgetPrivate in
1) put your 'd_ptr' into a smart pointer of some kind (usually
QScopedPointer), your example leaks memory;
2) placing 'q_ptr' in the public section doesn't make much sense because
it's supposed to be used only by the DisplayWidgetPrivate instance to
access its "owner" (DisplayWidget doesn't need an
Hi
I am developing a library and in Qt Tradition I want to use the d_ptr pattern.
I have no previous experience of using this pattern and have a simple example
working but wanted to check that my implementation is correct.
To that end I have set out my classes below and would be grateful if anyone
