А по теме:

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

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

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

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

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

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

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

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

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

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

Все Вам правильно объяснили, чего тормозите? Сделать множ вставку в 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;
}

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


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

Won't fix.

Поставят -1.