QList::insert (multi)

[ViTech]

А по теме:

С удивлением обнаружил что QList умеет вставлять только "по одному" - пришлось использовать вектор указателей. Не беда, но все-таки.. Или я плохо читал букварь?  Плиз "ткните носиком"

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

[Авварон]

Сколько аллокаций в последней строке?

Для QString сработает как вектор (sizeof(QString) == sizeof(void *)), поэтому вероятно ни одной (пул). Размер QImage навскидку не помню, наверное > sizeof(void *) (если не так поправьте), поэтому кроме вставки в массив указателей будет еще и выделение блока для эл-та QImage - хотя это и не оптимально. Да, возможно для хранения QImage(й) оптимальнее QVector, особенно с учетом implicit шары. И что? Не вижу никаких оснований для "снисходительной иронии"  (на базе сомнительной статьи).

Всё верно. Вас устраивает контейнер, который для одних _кутешных_ типов эффективен, а для других - нет? И без знания что "у ей внутре" не скажешь, подойдет лист, или нет.
К примеру, QVariant - плохой тип для листа, хотя есть QVariantList и он много где используется.
К 6ке вроде бы закопают qlist. Ну я на это надеюсь.

Вообще, std::deque лучше примерно всем.

[Авварон]

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

Ну удачи написать внешний range-insert))))

[Авварон]

. Мне вот идея QList кажется весьма разумной, многие ситуации он покрывает, пусть не все.

Аллоцировать на каждую вставку чтобы сэкономить немного бинарного кода в QtCore? Отличная идея!

[Igors]

Вас устраивает контейнер, который для одних _кутешных_ типов эффективен, а для других - нет? И без знания что "у ей внутре" не скажешь, подойдет лист, или нет.

В принципе - да, устраивает, хотя (за европейскую зарплату) мог быть и лучше. И да, любой контейнер эффективен для одних типов, но не для всех. И знать потроха (хотя бы в общих чертах) обов'язково.

Вообще, std::deque лучше примерно всем.

К сожалению, MSVC реализация ставит на нем крест Да и в других размера чанка не хватает, поэтому давно использую самописную деку. Насчет "всем" это Вы конечно загнули, он силен только на push_back, но во многих задачах это важно.

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

Мда, сегодня наверное "не Ваш день", сделаю вид что не слышал 

[ViTech]

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

Ну удачи написать внешний range-insert))))

Я говорил в общем о подходе. Определяется необходимый и достаточный набор методов для контейнеров (в STL описываются в Named requirements), остальное выносится в алгоритмы.

Имея метод

Код

C++ (Qt)
QList::iterator QList::insert(QList::iterator before, const T &value)

нужно какую-то rocket science применить, чтобы внешний range-insert написать? Эффективность такого решения - отдельный разговор.

[ViTech]

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

Мда, сегодня наверное "не Ваш день", сделаю вид что не слышал 

А что не так? Сделайте мой день .

[Авварон]

нужно какую-то rocket science применить, чтобы внешний range-insert написать? Эффективность такого решения - отдельный разговор.

Смысл member range-insert у вектора - одна аллокация и один сдвиг хвоста вектора.
Без доступа к методам reserve(), end() ничего не выйдет.
Так что удачи с генерик алгоритмом.

[Авварон]

В принципе - да, устраивает, хотя (за европейскую зарплату) мог быть и лучше. И да, любой контейнер эффективен для одних типов, но не для всех. И знать потроха (хотя
бы в общих чертах) обов'язково.

Ну вектор себя ведет примерно одинаково независимо от типа (исключение - вектор булов, тут комитет как всегда лоханулся)

К сожалению, MSVC реализация ставит на нем крест Да и в других размера чанка не хватает, поэтому давно использую самописную деку. Насчет "всем" это Вы конечно загнули, он силен только на push_back, но во многих задачах это важно.

Интересно, не знал. А в новой студии не поправили?
А как же insert, он тоже быстрее становится - достаточно подвинуть чанк а не весь хвост.

[ViTech]

Смысл member range-insert у вектора - одна аллокация и один сдвиг хвоста вектора.
Без доступа к методам reserve(), end() ничего не выйдет.
Так что удачи с генерик алгоритмом.

Прям совсем ничего не выйдет? Или не выйдет оптимально(по каким-то критериям)? И при чём тут конкретно вектор(я так понимаю std::vector имеется в виду)? Других контейнеров, куда можно вставлять в заданную позицию, не существует?

[Igors]

А в новой студии не поправили?

Не знаю, но если так зависеть от реализации - зачем тогда std?

А как же insert, он тоже быстрее становится - достаточно подвинуть чанк а не весь хвост.

Так не выходит, эл-ты во всех последующих чанках тоже надо месить. Дека очень важна когда счет идет на мульены, тогда пере-распределение "всего" (вектор) просто вешает ОС.

А еще хороший малоизвестный контейнер sequence (?) насколько помню так он называется в std. Доступа по индексу нет, просто можно создавать новый эл-т (обычно для хранения его указателя в др контейнере) и "удалять" (мнимо). Типа кастомной кучи/аллокатора.

Смысл member range-insert у вектора - одна аллокация и один сдвиг хвоста вектора.
Без доступа к методам reserve(), end() ничего не выйдет.
Так что удачи с генерик алгоритмом.

Прям совсем ничего не выйдет? Или не выйдет оптимально(по каким-то критериям)? И при чём тут конкретно вектор(я так понимаю std::vector имеется в виду)? Других контейнеров, куда можно вставлять в заданную позицию, не существует?

Все Вам правильно объяснили, чего тормозите? Сделать множ вставку в QList я не могу т.к. доступ к массиву указателей наглухо перекрыт (из идейных соображений). Да и вообще, чего это, взяв готовый/штатный контейнер, я должен его "доделывать"? У др контейнеров с доступом по индексу этот ф-ционал всю жизнь был. Ну а о том что вставка/удаление для таких контейнеров - удовольствие дорогое, и оптимизировать их программист просто обязан - и напоминать неудобно.

[GreatSnake]

Understand the Qt containers.
Статья уже старая, но для общего понимания довольно-таки неплоха.

[ViTech]

Все Вам правильно объяснили, чего тормозите?

Отсылки к частной реализации частной операции в частном контейнере и постоянные пожелания удачи как-то слабо тянут на "правильное объяснение". То, что из множественных вставок по одному элементу в контейнер, который для этого плохо подходит, ничего хорошего не получится - это и ежу понятно. Но это не значит, что так делать в принципе нельзя и "ничего не выйдет". Про эффективность я сразу отметил.

Сделать множ вставку в QList я не могу т.к. доступ к массиву указателей наглухо перекрыт (из идейных соображений). Да и вообще, чего это, взяв готовый/штатный контейнер, я должен его "доделывать"?  У др контейнеров с доступом по индексу этот ф-ционал всю жизнь был.

Вы, похоже, много всего не можете сделать . Но это, опять же, не означает, что это в принципе невозможно сделать. Почему не пользуетесь теми другими хорошими контейнерами, зачем Вам плохой QList? Если вернуться к баранам и говорить конкретно о QList, то можно предложить такие варианты:

1. Написать в Qt feature request на добавление нужных методов insert.
2. Самому пропатчить Qt и добавить нужные Вам методы insert.
3. Написать функцию, которая в QList вставляет несколько элементов по одному.
4. Воспользоваться готовым алгоритмом из STL:

Код

C++ (Qt)
#include <QList>
#include <QDebug>
#include <iterator>
 
int main()
{
    QList<int> a = {1, 2, 7};
    QList<int> b = {1, 2, 3, 4, 5, 6, 7};
 
    std::copy(b.begin() + 2, b.end() - 1, std::inserter(a, a.begin() + 2));
 
    qDebug() << a;
}

Да, стандартные алгоритмы работают даже с ущербными кутешными контейнерами, если в них есть необходимый базовый функционал.

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

Ещё неудобно напоминать, что для конкретной задачи нужно подбирать контейнер, который для неё подходит оптимальным образом. Вы, похоже, методом тыка выбираете: есть ли в контейнере нужные методы или нет, а не исходя из его характеристик и назначения. Ну и для каких задач предназначен контейнер, мы опять скорей всего не узнаем. Может нужно делать миллион вставок по десятку элементов в разные места контейнера? Расскажите ещё раз, что если Вы не указали что-то, то нужно подразумевать то-то, если не отметили другое, то это обозначает третье. Очень интересно послушать .

[Авварон]

Отсылки к частной реализации частной операции в частном контейнере и постоянные пожелания удачи как-то слабо тянут на "правильное объяснение". То, что из множественных вставок по одному элементу в контейнер, который для этого плохо подходит, ничего хорошего не получится - это и ежу понятно. Но это не значит, что так делать в принципе нельзя и "ничего не выйдет". Про эффективность я сразу отметил.

Эта частная операция в частном (vector, deque) контейнере позволяет снизить сложность алгоритма вставки в середину с O(M*N) до О(N). Утверждать что такая оптимизация не нужна for the sake of algorithms не оч умно так-то.

[Авварон]

1. Написать в Qt feature request на добавление нужных методов insert.

Won't fix.

2. Самому пропатчить Qt и добавить нужные Вам методы insert.

Поставят -1.