И в Qt6 решили выпилить QList, QStringList и заменить их stl-ным вектором.

Можно пруф?

Когда ты пишешь QList<Classname>, на самом деле выделяется массив указателей, а для каждого Classname'а делается отдельный new.

Я понять не могу, а что, если вектор будет хранить указатели на хранимые значения

Нет, вектор хранит значения последовательно в виде массива.

Он же не сможет хранить непосредственно сами объекты, например QString

QString — по сути объект, который содержит размер и указатель на строку (которая выделяется и перевыделяется отдельно от самого QString'а). Размер QString'а разумеется фиксирован.

Более, того, каждый стандартный QObject содержит лишь один указатель на еще один объект, который уже и хранит все данные. Это называется d-pointer и нужно для стабильного ABI.

плохо кешируются процом

Какая к черту локальность, если у них все равно везде d-pointer'ы?

Какая к черту локальность, если у них все равно везде d-pointer'ы?

Спасибо тебе, ты побудил меня гуглить. Я видел нечто подобное в кутэшных исходниках, но не придал значение.

Сейчас посмотрел в qlist.h — нашёл несколько комментариев вида // ### Qt6: use int перед разнообразными typedef, из чего делаю вывод, что планируется какая-то работа, но никак не удаление

Оказывается, QList неоптимально работает, и его собираются выпиливать из Qt. ... И в Qt6 решили выпилить QList, QStringList и заменить их stl-ным вектором.

Где можно про это прочитать? Да и вообще, есть очень большой класс задач, когда все равно нужно хранить именно указатели, вставлять в начало/конец, и тут вектор, очевидно, сольет QList.

По ссылке не ходил, но выпиливать его на 99.99% не будут. Максимум изменят реализацию.

Я понять не могу, а что, если вектор будет хранить указатели на хранимые значения, то будет легче? Он же не сможет хранить непосредственно сами объекты, например QString, в виду разного обжектсайза у разных строк, которые к тому же могут меняться.

Почему не сможет? Как это разный обжектсайз у разных строк? «обжектсайз» всегда одинаковый.

Бред. Тем более что в Qt есть свой вектор.

в виду разного обжектсайза у разных строк

sizeof для любого типа всегда фиксирован и определяется на этапе компиляции. Про сишников с их VLA не вспоминаем

Удаление QList невозможно, т.к. для огромного числа задач требуется именно такое поведение. Но можно оптимизировать работу QList каким-то образом, что скорее всего и будет сделано. Не более того.

Удаление QList невозможно, т.к. для огромного числа задач требуется именно такое поведение. Но можно оптимизировать работу QList каким-то образом, что скорее всего и будет сделано. Не более того.

Чего это удаление QList невозможно? Аналога ему ведь в STL вроде нет(или я что-то пропустил?) и ничего как-то живут без этого.
QList это такой гибрид пытающийся в себе сочетать алгоритмическую сложность доступа QVector(std::vector) и добавления QLinkedList(std::list).

QList это такой гибрид пытающийся в себе сочетать алгоритмическую сложность доступа QVector(std::vector) и добавления QLinkedList(std::list).

Ясно... Про QLinkedList я как-то забыл.

QList хранит указатель только, если тип, которым он параметризируется не помещается в размер указателя. Заменять его на std::vector не очень разумно, они все же разные, т.к. QList использует неявное разделение данных. Ну а кроме того, лично я нахожу API STL'ных контейнеров не очень удобным (достаточно сравнить работу с std::map и QMap, в первом случае лишней писанины будет больше). Хотя да, тенденция перехода на STL'ные аналоги наметилась еще начиная с Qt5.

два чая этому господину. std::map неюзабелен вообще.

А теперь попробуй создать QMap с нестандартным компаратором

А теперь попробуй создать QMap с нестандартным компаратором

А в чем там собственно проблема уважаемый?

The key type of a QMap must provide operator<() specifying a total order.

https://marcmutz.wordpress.com/effective-qt/containers/#containers-qlist

Проблема в том, что operator< для конкретного T может быть только один, и если он уже где-то объявлен, то придется городить огород с неймспейсами, чтобы обеспечить однозначность

QList это такой гибрид пытающийся в себе сочетать алгоритмическую сложность доступа QVector(std::vector) и добавления QLinkedList(std::list).

Неа. Он пытается обеспечить сложность добавления std::deque, до связного списка ему далеко

А теперь попробуй создать QMap с нестандартным компаратором

Он еще и нестандартные аллокаторы не умеет. Речь не о замене stl::map на QMap, а о более человекоудобном интерфейсе последнего. Просто разработчики Qt задумываются об удобстве прграммиста, а комитету стандартизации C++ на это удобство насрать.

А зачем тебе городить разные operator< ? Там где не требуется сортировка можешь юзать метод вместо operator<.

А зачем тебе городить разные operator< ?

Может быть, чтобы задать нужный порядок сортировки в QMap? Ну ты и тугой.

Если это настолько надо, лучше создать свой контейнер, чем портить интерфейс существующего, расширяя его подобными настройками

Копировать реализацию красно-черного дерева только ради того, чтобы заменить operator< на другую функцию? Пффф.

зачем тебе два оператора < ?

блин, чего им не живётся спокойно? в мире миллионы библиотек, Qt - лишь одна из них. на ней свет клином не сошёлся, кому не нравится этот лист, может юзать что угодно, либо сам может написать нужные заготовки, с пулами и прочее, если оно того стоит. в большинстве приложений с использованием Qt проблемы тормозов точно не в листах. а те, кто пишет с оптимизацией, на которой заметны провалы в кэше проца, те точно Qt не юзают.

в мире миллионы библиотек, Qt - лишь одна из них.

можно список первой сотни этих библиотек, которые имеют примерно функционал qt ?

Аналога ему ведь в STL вроде нет(или я что-то пропустил?)

собственно, list<>

Не, std::list — это STL-ный аналог QLinkedList. Аналогом QList<T> в STL является std::vector<T*>

в плане графики - хз, я особо не занимаюсь юзерской фигнёй. но если мне если вдруг нужно гуй прикрутить по-быстрому, я беру wxWidgets - он легче Qt и гораздо шустрее. в плане функционала по работе с системой и всякого полезного барахла - boost или ACE. оба куда круче Qt по производительности. есть масса специальных библиотек для работы с сетью (типа poco). и Qt сурово сливает всем этим библиотекам по скорости и по объёму в памяти. её можно использовать только для низкопроизводительных и малонагруженных юзерских софтин.

я особо не занимаюсь юзерской фигнёй

но в треде отметится надо, ок

boost или ACE. оба куда круче Qt по производительности.

можно ссылки на примеры? где qt «сурово сливает всем этим библиотекам по скорости» работы в сети например

в чем смысл использовать несколько разных библиотек (boost и ACE и wxWidgets и poco или еще чтто) вместо одной qt ?

нет. просто Qt тащат везде. мода такая. клепатели формочек хреновы. развелась куча говнософта, который жрёт ресурсы. и туда же: кэш процессора им мешает! да в этом юзерспейсном болоте до кэша процессора как до луны пешком. обвинять обычные тормоза культи промахами в кэше - это просто верх маразма.

мода такая. клепатели формочек хреновы.

что из этого считаешь ненужным http://doc.qt.io/qt-5/qtcore-index.html ?

суровые систематики пишут все сами, свои квадратные колеса быстрее едут ?

клепатели формочек хреновы

Qt разбит на модули, причём тут гуй? Можно писать и без гуя. И буст по-моему гораздо жирнее кьюта

где qt «сурово сливает всем этим библиотекам по скорости» работы в сети например

Напиши и померяй. Включая память и загрузку проца. IMHO весьма общеизвестный факт.

Напиши и померяй. Включая память и загрузку проца. IMHO весьма общеизвестный факт.

я не должен доказывать чужие утверждения

выпилить QList, QStringList и заменить их stl-ным вектором

давно пора

Дело твое, я просто подтвердил слова Iron_Bug. Как ты догадываешься, тебе специально пример писать я тоже не буду.

IMHO весьма общеизвестный факт.

нет такого общеизвестного факта.

такой я ответ и ожидал

Мнение о QList

По мне так QList должен был быть предназначен не для рядового динамического массива, а для массива, который гарантирует, что адрес каждого элемента будет постоянным в независимости от того, что из массива удалили или куда вставили (за исключением, если сам массив был скопирован, то элементы в новой копии уже очевидно будут иметь другие адреса)

Я сначала так и пользовался QList-ом, однако с ним начались странные глюки и либо попадались левые элементы, либо вообще мусор, хотя это был (Qt 5.6), и я в итоге состряпал себе свой контейнер (кому любопытно, тут https://github.com/WohlSoft/PtrList) (сначала полностью с нуля, а затем новую версию унаследовал от std::vector, потому что он оптимизирован лучше, проверил несколькими бенчмарками)