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

David Hampton mythtv at dhampton.net
Sat Jun 3 00:06:33 UTC 2017


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)

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.

There are simple solutions for a couple of these files. The
MetaGrabberScript object defined in metadatagrabber.h doesn't appear to
use any of the properties of a QObject, so a one line change to make it
a standalone class produces a clean compile. The simple solution for
the MythSystemLegacy object boils down to removing the unused copy
constructor.

The solution for the FileSystemInfo object is fairly straight forward.
The copy constructor can be removed, and the rest of MythTV can be
modified to pass around pointers (or lists of pointers) to
FileSystemInfo objects. There is some ripple effect into a few other
files, as direct references to object functions have to be converted
into indirect references to the same functions.

The MythCookieJar object in mythdownloadmanager.cpp needs a little more
thought given to how to fix it. Aside from loading/saving cookies, its
purpose appears to be to copy cookie jars from one network manager to
another. This makes it hard to not want a copy constructor. Perhaps
instead of creating new cookie jars each time, a way could be found to
use the allCookies/setAllCookies functions and only update the contents
of the jars, not create new jars each time.

The last problem is everything in under libmythservicecontracts. All of
these objects defined under this directory declare and register
metatypes for both the object and a pointer to the object. This sets up
a contradiction though, as using the Q_DECLARE_METATYPE macro on an
object requires that the object have a public copy constructor and
being based on QObject requires that it doesn't. This contradiction
doesn't extend to *pointers* to objects based on QObject; in fact
pointers to classes derived from QObject are automatically registered
with the QMetaType system and you don't even need to use the
Q_DECLARE_METATYPE macro. The CopyListContents function in
datacontracthelper.h also needs to be tweaked as its current form
implicitly creates copies of objects.

If anyone has any thoughts on any of this I'd love to hear it. I have
prototype changes that compile cleanly, and I can start a
backend/frontend pair and perform basic actions like watching
recordings and videos, visiting web sites, etc.  If anyone wants to
look through my diffs I can post them somewhere (or create a pull
request, although I know several of the fixes still need refinement).

Thanks for reading this far.

David






More information about the mythtv-dev mailing list