[Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Marc Mutz]

On Saturday 27 February 2016 00:56:08 Thiago Macieira wrote:
> Have I convinced you? I'm only getting warmed up. I'm sure I can find more 
> issues.

That's all correct. But can't we create a subset of features that the QObject 
template may use in order to make that subset work? After all, function 
templates as slots don't work in classical QObject, either, so we don't lose 
anything by banning them in QObject templates, either.

As for the staticMetaObject, moc could  write its output not as C++ code, but 
as a macro containing the C++ code, for QObject templates, to be called with 
those QObject template instantiations that the user creates (similar to the 
old method of template instantiation where the user needs to list the explicit 
template instantiation in a separately-compiled TU). Only one TU would contain 
the macro call for any given instantiation, solving the multiple-definition 
problem you mentioned.

  template <typename T>
  class ListModel : QAbstractListModel {
      Q_OBJECT_TEMPLATE(T)
  public:
      // ...
  };

  // in some other TU

  #include "listmodel.moc"
  Q_MOC_INSTANTIATE(ListModel, MyStruct)
     // resolves to something like
     // Q_MOC_INSTANTIATE_ListModel(MyStruct, #MyStruct)

  void Foo::Bar() {
      auto *model = new ListModel<MyStruct>(this);
      // use 'model'
  }
  ... other code ...

Partly, this can already be emulated by just not including the Q_OBJECT macro 
in the QObject template and then deriving non-template QObjects from it that 
do contain the Q_OBJECT macro, hiding the actual subclass from moc with 
Q_MOC_RUN. This would just move the boilerplate code into moc's hands, where 
it belongs.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts