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

Milian Wolff milian.wolff at kdab.com
Thu Feb 25 19:22:55 CET 2016


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/d09c90e
> 
> 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
-- 
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/20160225/1d62b8d1/attachment.bin>


More information about the Development mailing list