Вот давайте и сделаем для конкретной задачи. А то что будет на ++ я переживу  

Чтобы удалить элемент из середины, QList сдвигает 20(40)К байт

Наоборот, QList справляется с non-movable данными, а QVector нет и std::vector нет. Если sizeof элемента QList меньше sizeof(void *), то элемент может и не иметь конструктора копирования и оператора присваивания, а также можно спокойно использовать указатель на элемент - он не изменится при вставке или удалении др. элементов. А с вектором это рухнет (причем подло, не сразу).

А я и не говорил что это должен быть С массив. Просто др структуры данных вместо стандартных. Вообще ну зачем так сразу плохо думать о человеке... типа "ага, он не знает что есть вектор и до сих пор использует С массив". А может он знает но "сомневается"?  

memmove т.к. поля перекрываются

Может у нас разное определение movable и non-movable типов. У меня такое определение:


QList не хранит данные непосредственно (за исключеним если sizeof(T) имеет размер поинтера и может! быть перемещен - movable type). Он хранит указатели на данные. А указатель это movable или non-movable тип? ))

По поводу QVector. Он сам определяет, какие данные он содержит, movable или non-movable. Все кастом типы по определению non-movable. Но мы можем из них сделать movable при помощи Q_DECLARE_TYPEINFO.

Ну обернуть я и сам могу    А это место у меня (увы) на ++ (std::vector). Получается и некрасиво, и некоротко. Есть идеи оригинального контейнера - обсудим.

Спасибо за Q_DECLARE_TYPEINFO.(этого не знал). Я имел ввиду

C++ (Qt)
struct Piggy {
   Piggy  ( void ) : mType(0), mStr(0) {} 
  ~Piggy ( void )  { delete [] mStr; }
 
// data
  int mType;
  char * mStr;
};
 
// использование
 QList <Piggy > lst;
 lst.push_back(Piggy());
 Piggy & p = lst.back();
 p.mStr = new char[128];
 strcpy(p.mStr, "Test");
 

Это пройдет с QList, но не с QVector (std::vectior). Это может быть важно когда копирование по каким-то причинам недопустимо (напр др объект держит указатель на созданный элемент).

Разница та что в С (и векторе) можно получить указатель на массив, а с QList нет.

Пантер немного промахнулся с названием новой темы. С "просто массивами" обсуждать нечего, а вот с альтернативными (самопальными) контейнерами - очень даже есть чего. Предлагаю переименовать в "Альтернатива стандартным контейнерам (?)"

Пантер, как хотите, у меня претензий нет. Просто слышу много писка, мол, "изобретаешь велосипед". "знание STL", "а вот в дусте можно и так" и.т.п. А по работе (на практике) получается куда не все так радужно и просто как в учебных примерах.  Никто не против выучить стандартное (не дураки тот же STL придумали) и спокойно пользоваться  - да вот не всегда получается  Где-то с 1 миллиона полигонов в сцене все проблемы/огрехи начинают (настойчиво) напоминать о себе. На 5 млн уже "как бы проскочить". На 10 - "надо что-то делать потому что так не годится".

1. Igors, не понял на счет выканья.
2. "Писк" немного оскорбляющее слово.
3. У тебя очень часто "сишный подход".
4. Тему я отделил не для того, чтобы над сишными массивами (или над тобой) поглумиться.

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

C++ (Qt)
char *XXX

передается из класса в класс, из функции в функцию, и не понятно кто создает/удаляет эту хрень.  (самое интересное, что утечек памяти нет - это означает, что программист мнооооооого времени провел за отладкой). В общем, баг был в том, что в один из моментов обращения к указателю валило прогу.
К чему это я?
Ну, с контейнерами такого бы не получилось. Т.е. вероятность бага снизилась бы.
Если пишешь на чем-то, то и используй средства этого языка. Ведь не очень красиво будет писать вот так:
"My imja is Panter. I'm zhivu in Russia. I l'ubl'u this forum".

С твоими требованиями, самое простое, это придумать свою структуру хранения данных, лишенную всяческих недостатков.  Этакий IdealContainer. 

Тебе с одной стороны хочется что бы памяти много не кушал, с другой стороны, что бы доступ был быстрым, а вставка/удаление выполнялось бы за O(1)....

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