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

[Milian Wolff]

On Freitag, 26. Februar 2016 09:43:40 CET Jędrzej Nowacki wrote:
> 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/d09
> > > > c9
> > > > 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.

Can you explain how you imagine the code to look like for the model to notify 
the view about changes? Curtis' note on QML requiring introspection for models 
is also very valid.

>  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

Thanks for the link. How often is the MOC layout changed in an ABI 
incompatible way? I.e. what problems would we get from having to install the 
moc files?

Alternatively: couldn't moc re-create the required data from included files 
when they contain templated objects? That would solve the problem as well, no?

Cheers

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160226/6a75aabc/attachment.bin>