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 | [email protected] | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
