QTableWidget vs QTableView (холиварчик)

[Majestio]

Всегда пользовал QTableView ...

Но часто вижу что народ работает с QTableWidget.
Выскажитесь плс, какие методы/способы использования QTableWidget могут существенно сократить время программинга, размер кода в сравнении с QTableView? 

[Bepec]

Создание модели, реализация драг енд дропа, реализация стороннего взаимодействия.

Лишний класс с базовым функционалом - зачем?

[Majestio]

Лишний класс с базовым функционалом - зачем?

Вот и я о том же, как еще говорят - и доступ к данным ячеек у QTableWidget через Ж 

[Bepec]

Я это говорил про QTableView + модель (две сущности)
Против QTableWidget (одна сущность)

[Majestio]

Я это говорил про QTableView + модель (две сущности)
Против QTableWidget (одна сущность)

Погоди, а что для QTableWidget служит источником данных?

[gil9red]

Тоже модель, но она "встроенная"

[kambala]

по идее *Widget потребляет больше памяти, чем *View, особенно разница будет заметна на больших объемах данных

[Bepec]

Вот пошли комментарии по делу

Да, памяти она сожрёт больше, ибо она многофункциональнее А на малых объемах *Widget быстрее и проще. Как говорится если ты уверен, что количество элементов ограничено  и будет меньше пары сотен, можно смело использовать *Widget

[Majestio]

Тоже модель, но она "встроенная"

Т.е. все, что "встроено" сущностью не считается? 

Вопрос намба ту ... для себя я принял за правило хорошего тона - делать модель не "хранилищем", а "средством доступа к данным". Иными словами:

- умеет читать данные из источника
- умеет распределять ресурсы
- умеет кешировать
- умеет сортировать (для последующего чтения)
- умеет фильтровать (для последующего чтения)
- умеет отдавать запрошенное в результате

... все это делает что-то другое (другой класс или набор процедур) ... А модель должна только уметь получать и обработав, предоставлять. Есть один минус этого подхода - изменение данных и последующую запись в БД через модель я не делаю (вместо этого записываю непосредственно и обновляю). Но минусом я это не считаю, ибо подход прошел полевые испытания и очень таки успешно. Транзакции и блокировки при многопользовательском доступе реализуются вполне приемлемо по объему кодирования и понятности. Практически "копи-паста". Критикуйте! 

Вопрос намбе сри ... Каков функционал встроенной модели? Встроенная модель может, к примеру, отдавать данные из трех принципиально разных источников, предварительно их скомбинировав? Например, из БД, датчика оборотов системного кулера, текущих параметров NDIS?

[Bepec]

1) Не считается. Она скрыта от меня И у меня в файле отсутствует класс модели как таковой.

2) Что критиковать? Это свободный выбор. Пусть я не имею пока знаний по кеширования /фильтровке и прочему - это ваш выбор и ваш путь. Аналогично использованию QThread - кто-то наследуется, кто-то moveToThread туда свои классы.

3) Вы не путайте базовый функционал и специфический. Базовый - представить таблицу. Он им обладает. Все действия с таблицей реализованы.
Специфический - заполнение и изменение данных лежит на вас и ... Та дааам - да, вы можете читать данные из трёх источников и менять их в таблице.

PS не пытайте ровнять лопату и мотокультиватор.
Лопатой при должном умении можно сделать всё.
Мотокультиватор же делает специфические вещи лучше и быстрее лопаты, но только их

[Akon]

*Widget классы это Item-based technics, которая была единственной в Qt3, если не ошибаюсь. Потом сделали Model-View как более фундаментальную и функциональную фичу, а Item-based натянули поверх (типо для тех, кто "привык").

Majestio +1.

В более/менее функциональных прогах:
Data
Business Logic (C++ classes, ORM)
QAbstractItemModel-наследник: манипуляция данными через Business Logic
View для представления

[GreatSnake]

по идее *Widget потребляет больше памяти, чем *View, особенно разница будет заметна на больших объемах данных

Всё зависит от используемой модели.
Если использовать *View и QStandardItemModel, то, имхо, разница будет минимальной.

[Bepec]

Widget это view со стандартной моделью и с максимально расширенным функционалом. Кто не верит - прошу в ассистент.

Комментарий Akon уходит в небытие - это не пережиток Qt3, а удобное и быстрое решение для простых решений.

to GreatSnake - разница будет. Там много функционала. А своя моделька голая.

[GreatSnake]

Widget это view со стандартной моделью и с максимально расширенным функционалом. Кто не верит - прошу в ассистент.

Что имеется в виду под "стандартной моделью"?
Если QStandardItemModel, то утверждение неверное, ибо
для QListWidget используется приватная QListModel,
для QTreeWidget используется приватная QTreeModel,
для QTableWidget используется приватная QTableModel

to GreatSnake - разница будет. Там много функционала. А своя моделька голая.

чего-то не понял про какую разницу идёт речь

[Bepec]

Сужу по Qt 4.7.2 и документации на 5.1

QListWidget и прочие Widget являют собой список Q*WidgetItems. Т.е. каждый элемент представляется отдельно. Отдельно для каждого выделяется место под роли/текст/данные/шрифт/ прочие атрибуты, которые возможно пригодятся (именно это я имею в виду как широкий функционал).

Т.е. QListWidget/QTableWidget/QTreeWidget являют собой просто совокупности QListWidgetItem/QTableWidgetItem/QTreeWidgetItem. Занимаемое место растёт линейно количеству элементов и их атрибутов.

Свой же View и модель дают совокупность данных и единые атрибуты для всех элементов (метод data). При желании оно может конечно разбухнуть, но врят-ли до таких размеров, как *Widget.

Сейчас Widget пример докачает миллион элементов в память и я выложу реальные цифры. А пока жду


Update: Предупреждение, картинка на 500 кб.
Обе программы содержат миллион строк "tratata". Разница только в Widget/View и процессе заполнения.
Разница в 3 раза по памяти. 

PS это не плохо. Это нормально. На малых объемах данных мне лично удобнее использовать Widget не продумывая модель и роли. К тому же такое поведение можно менять в любой момент и в любом месте ^.^