QList потомки - структура или пользовательские классы, полученные из QObject - PullRequest
3 голосов
/ 30 апреля 2011

В настоящее время я работаю над приложением Qt на платформе Symbian.Приложение имеет базу данных sqlite и исходные данные заполняются из текстовых файлов.

Я внедряю онлайн-обновление данных в формате json.Поэтому я хотел бы создать универсальные функции в моем классе обновления базы данных, который берет QList классов / структур и обновляет базу данных из них.QList будет заполнено объектами из txt или json.

У меня уже есть разбор на месте, просто учитывая, что было бы лучше с точки зрения производительности:

  1. Создание структур c ++ и их передача (поскольку объекты содержат только простые данные), завернутые вQList
  2. Создание пользовательских классов, производных от QObject и передача их в виде указателей в QList, а затем удаление всего с помощью qDeleteAll
  3. Любым другим способом ...

1 Ответ

2 голосов
/ 30 апреля 2011

Это зависит от того, ведут ли ваши классы поведение или только состояние.

  1. Они несут поведение.

    Тогда полиморфный класс в порядке, да. Нужно ли наследовать от QObject - это другой вопрос. Наследуйте от QObject только , если вам нужны его услуги (самоанализ, сигналы / слоты, обработка событий). В противном случае, не надо.

    Что касается qDeleteAll(): я бы туда не пошел. Вместо голых указателей используйте умные указатели, например, QSharedPointer. Они отслеживают количество ссылок на свою полезную нагрузку, удаляя их, когда количество ссылок падает до нуля.

    В этом случае не используйте QList, но более эффективный контейнер, такой как QVector.

  2. Они несут только состояние.

    Тогда "немого" struct может быть достаточно. В этом случае не используйте QList в качестве контейнера, но что-то более эффективное, например QVector (не забудьте использовать метод reserve()).

В общем, старайтесь избегать QList<T> для типов T, где sizeof(T)>sizeof(void*) и не-buildin / non-Qt-типов, потому что производительность QList для этих . * 1043 снижена *

...