[mythtv] "base class should be explicitly initialized" errors

[David Hampton]

On Tue, 2017-06-06 at 10:45 +0200, Jean-Yves Avenard wrote:
> Hi
> 
> On 3 June 2017 at 02:06, David Hampton <mythtv at dhampton.net> wrote:
> > Hi all. I'm still slogging my way through all the warnings created
> > by
> > adding the -Wextra flag to compiles, and decided it was finally
> > time to
> > tackle this class of warning:
> > 
> >   In copy constructor ‘blah::blah(const blah&)’:
> >   warning: base class ‘class QObject’ should be explicitly
> >   initialized in the copy constructor [-Wextra]
> >   blah::blah(const blah &other)
> 
> Yes, the base constructor must be called here.. I'm surprised it
> could
> ever compile without it.
>
> > 
> > This warning occurs on objects defined in these files:
> > 
> >   libs/libmythbase/filesysteminfo.h
> >   libs/libmythbase/mythdownloadmanager.cpp
> >   libs/libmythbase/mythsystemlegacy.h
> >   libs/libmythmetadata/metadatagrabber.h
> >   libs/libmythservicecontracts/enums/recStatus.h
> >   Everything under libs/libmythservicecontracts/datacontracts
> > 
> > The trivial solution would seem to be initializing the base qobject
> > in
> > the copy constructor, only that results in a different bunch of
> > warnings like this:
> > 
> >   In copy constructor ‘blah::blah(const blah&)’:
> >   error: ‘QObject::QObject(const QObject&)’ is private within
> >   this context : QObject(other)
> >   /usr/include/qt5/QtCore/qobject.h: note: declared private here
> >      Q_DISABLE_COPY(QObject)
> > 
> > That got me researching the topic, which led me to these
> > references..
> > 
> >     http://doc.qt.io/qt-5/qobject.html#Q_DISABLE_COPY
> >     https://www.ics.com/designpatterns/book/qobject.html
> > 
> > ..which basically say you should never copy things derived from a
> > qobject. They represent unique entities, not things that can be run
> > through a xerox machine.
> 
> well you can, but not a plain QObject. But things like QString and so
> on, handle Copy on Write

QString isn't derived from QObject.

The problem as I understand it is this: QObject supports parent/child
object relationships using a single pointer for the parent and a list
for the children.  If you were to copy a QObject, you would get a new
object that points to a parent that doesn't know about it, but much
worse you would have two objects that contain the same list of
children. If either of these objects is destroyed, thereby destroying
all its children, the other object ends up holding a list of dangling
pointers.

This holds true for any object derived from a QObject. In order to
create a true copy of that object, you would need to copy the QObject
it is derived from. You can't do that without running into the same
problem as copying a plain QObject. On the other hand, if your "copy"
function doesn't copy the entire object including the base QObject, but
instead creates a new base QObject with no parent and no children while
copying everything else, is it truly a copy function? (I know, that
sounds like a semantics question.)

I don't have any right answers here. I'm just trying to figure out the
implications of the Q_DISABLE_COPY macro, and what's the right solution
for MythTV. I'll implement whatever the group decides is the right
solution.

David