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

[Curtis Mitch]

> -----Original Message-----
> From: Development [mailto:development-
> bounces+mitch.curtis=theqtcompany.com at qt-project.org] On Behalf Of Jedrzej
> Nowacki
> Sent: Friday, 26 February 2016 9:44 AM
> To: development at qt-project.org
> Cc: Thiago Macieira <thiago.macieira at intel.com>; Milian Wolff
> <milian.wolff at kdab.com>
> Subject: Re: [Development] templated QObjects [was: Re: We are planning to
> upgrade qdoc to use clang for parsing C++]
> 
> On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam
> wrote:
> > > > This might be a burden for some of the Qt developers (Windows ones).
> > > >
> > > > But all the Qt users get a modern / flexible moc, see this thread:
> > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked
> > > > /d09c9
> > > > 0e
> > >
> > > I don't think we need a more flexible moc. What do we want to do
> > > that we can't do with the current one?
> > >
> > > Don't say "template QObjects". That has other reasons for being a
> > > bad idea, currently.
> >
> > Can you explain what those reasons are? I'd really love to write a
> > generic QAbstractTableModel implementation that operates using
> > concepts. Currently that would require type erasure and thus another
> > set of virtual function calls...
> >
> > I.e. in many projects I end up writing the same boiler plate code to
> > display a QVector<MyRowType> in a view. As far as I can see most of
> > that could be abstracted away easily, leaving only slim concepts to the
> struct:
> >
> > struct MyRowType {
> > QString foo;
> > int bar;
> > QVariant data(int column, int role) const {
> >     if (!role == Qt::DisplayRole) return {}
> >     switch (column) {
> >       case 1: return foo;
> >       case 2: return bar;
> >     }
> >     return {};
> > }
> > };
> >
> > this could easily be extended to other methods, such as setData,
> > headerData, etc. pp. In the end, one would only need to implement a
> > trivial minimal API at the place where the data is actually stored.
> > And no, I do _not_ consider the current QAIM interface trivial to
> implement, not even for "simple"
> > lists!
> >
> > If we'd have templates QObjects, the above could easily be written. I
> > bet there are other valid use-cases.
> >
> > Cheers
> 
> Hi,
> 
>  When first time I heard about templated QObject, QAIM was my first
> thought :-) The thought evolved over last months and now I think that QAIM
> should not be QObject at all, it is just an unnecessary cost.

What about using C++ models in QML? QAbstractItemModel has to be a QObject for that reason alone. Often you also want to control the contents of the model by some UI-driven property in QML (e.g. a filter for a list of contacts based on a text input field).

>  The main problems of templated QObject are captured more or less in this
> thread: http://lists.qt-project.org/pipermail/development/2013-
> March/010288.html
> 
>  Personally I still think it would be a fancy feature, a bit dangerous to
> implement maybe even dangerous to use, but really cool :-D
> 
> Cheers,
>  Jędrek
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development