Qt QGraphicsScene.items() - получение данных пользовательского класса

У QGraphicsItem есть методы

void QGraphicsItem::setData ( int key, const QVariant & value ) 

QVariant QGraphicsItem::data ( int key ) const

Вот туда можно записывать значения своих данных.

А ваши варианты конечно работать не будут, так как QList <MovingObject*> и QList <QGraphicsItem*> это разные типы данных.

Но ведь один наследуется от другого! Т.е. метод scene.additem(new MovingObject()) работает полностью корректно, хотя это тоже объекты разных классов.

Спасибо, попробую метод setData

Указатель типа предок может указывать на наследованный объект, поэтому addItem работает нормально. А вот обратное не работает.

Да, я уже понял) проблему решил так:

  QList <QGraphicsItem*>objl;
    objl=scene.items();
    for(int i=0; i<objl.size(); i++)
    {
       MovingObject * mo = dynamic_cast <MovingObject *> (objl[i]);
       if (mo)
       {
           qDebug()<<mo->name;
       }

Это нормально, когда один нестандартный тип объекта на сцене. А вот расширяться будет очень накладно и код будет запутан.

dynamic_cast это медленно, проверка на nullptr тут не упала.

Обрати внимание на qgraphicsitem_cast

Всякие cast'ы в такой ситуации - это костыли.

QVariant - тот же каст, вид сбоку.

Если использовать setData() и data() не будет необходимости писать cast для каждого собственного класса. Пока наследованный класс - один-единственный, код будет небольшим, но как только классов будет куча - код сразу стане несопровождаемым.

Я думаю, будет не более 10 классов для отрисовки на сцене. Тогда такой вопрос - если я использую SetData(), мне нужно отказаться от пользовательского класса? И все объекты пихать в один лист, разделяя их например по ключу type?

Смотря что вам надо. Можно отказаться, можно не отказываться. Если вам надо например рисовать как-то по-своему - наследовать все равно придется.

И 10 классов - это уже очень много для cast'ов. Много лишнего кода будет.

А что ты будешь делать когда потребуется больше одного поля? Хотя вообще говоря у меня сложилось ощущение что ТС пытается из сцены сделать модель приложения, чего в общем-то делать не стоит.

В смысле, больше одного? setData имеет два параметра - ключ, значение.

Ну и на самый крайний извращенный случай: в QVariant можно запихнуть QVariantMap ;)

То есть даункаст тебе не нравится, а поиск по словарю в поиске QVariant'а который тоже нужно кастить чёрт знает к чему это ок? Вот ни разу не проще, не нагляднее и не быстрее. Кроме того QVariant это особа фишка Qt (довольно спорная, к слову), а даункаст — общеупотребительная для плюсов.

Да, Вы правы - скорее всего потребуется переопределение метода paint(), поэтому наследование классов делать придется. В этом случае наверное вряд ли получится работать с setData(), а придется приводить типы...

Даункаст мне не нравится потому что надо будет для КАЖДОГО наследованного класса писать отдельный кусок кода. И для КАЖДОГО добавляемого класса выискивать места в коде, а где же там надо его добавить.

Про скорость - на Qt получаются весьма шустрые GUI.

QVariant это особа фишка Qt (довольно спорная, к слову), а даункаст — общеупотребительная для плюсов.

Проект-то чисто Qt'шный, почему бы не использовать все его фичи.

А нет возможности вообще спрятать от сцены детали реализации наследников?

Эй! У тебя тут рантайм диспетчеризация. Если делать на QVariantMap'е ты будешь писать по обработчику на каждое отдельное поле которых будет не меньше чем классов в иерархии наследования. Злоупотреблять QVariant'ом не стоит. Он ослабляет и без того слабую типизацию.

Если использовать setData() и data() не будет необходимости писать cast для каждого собственного класса

Необходимо будет писать canConvert() для кастомных данных, а кроме того данные должны быть классом с метаинформацией. Мне представляется, что это работает немногим быстрее, чем dynamic_cast и уж точно медленее, чем qgraphicsitem_cast, который использует if+static_cast. Хотя, я могу и ошибаться.

Дело тут не в скорости работы программы же. А в том, чтобы не писать кучу if-cast для всех собственных классов.

Вообще, все это костыли и я бы подумал, а нельзя ли как-то скрыть детали реализации объектов сцены от других классов.