Il 03/11/18 03:16, Иван Комиссаров ha scritto:
Sure. Sorry for std::array_view (it maybe a QSet or QVector or gsl::span whatever more convinient/faster).The basic idea is here:In the model:void multipleData(QModelIndex index, std::array_view<Qt::ItemRole> roles, std::function<void(Qt::ItemRole,QVariant)> enumerator){ for (auto&& role: roles) { if (role == Qt::DisplayRole) { enumerator(role, data.at <http://data.at>(index.row()).text); if (role == Qt::EditRole) { enumerator(role, data.at <http://data.at>(index.row()).editText); } // …. } } In the view: QMap<Qt::ItemRole, QVariant> map auto enumerator = [&map](Qt::ItemRole role, QVariant data) {map[role] = data; // actually here’s the view’s code, painting data and so on, no need in intermediate container, I use it just for example}model->multipleData(index, {Qt::DisplayRole, Qt::BackgroundRole}, enumerator);
So, basically, a visitor pattern. In principle it's reasonable, but in practice, if you're using it like the above it becomes awkward and way less efficient than passing/returning a container.
It boils down to whether a view (... a delegate) would be more easily written with a visitor. A few experiments are necessary (e.g. rewrite QStyledItemDelegate as well as the corresponding QML code).
Not sure if std::function does not allocate in case of lambda, btw. I 80% sure it does, so returning a vector can be better. Anyway, one can look at the assembly in both cases and run a profiler.
Some std::function implementations feature a SSO, but in the general case you're going to have an allocation for it. Not a big deal, in general, as a view/delegate can just build the visitor function once and simply keep calling it.
Cheers, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
