Производительность стандартных контейнеров.

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

Ещё какая-либо библиотка?

folly, например

Знаю, что в Qt и в STL разные рекомендации по выбору контейнеров. В STL рекомендуют использовать std::vector, в Qt - QList.

Нужно сперва сформулировать требования к контейнеру (скорость выборки, добавления элемента, удаления элемента, расположение элементов контейнера в памяти) и сопоставить их с имеющимися реализациями.

Ты бы лучше конкретную задачу описал, а тебе скажут, какой контейнер надо заюзать.

В каждом отдельном случае - своё. А что надо-то?

Нас сколько помню, Qt это CoW контейнеры. Boost, чаще всего, повторяет STL, собссно все, то в буст - это, в большинстве, кандидаты в стандарт.

А еще реализации...есть eastl, например http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

везде хреновые, пиши свои

где-то на хабре читал мнение (правда, от сишника), что реализации vector-а STL медленные все, в принципе. мне нужно для POD, а там возможны оптимизации за счёт realloc. да и malloc с calloc на 5 копеек быстрее вызываются, чем new/delete.

В STL рекомендуют использовать std::vector, в Qt - QList.

На всякий случай, QList - это не аналог std::list, как можно подумать по названию. Вот тут есть информация, ну или в самой документации Ят. Уверен, что для простых типов std::vector выиграет.

Странный какой-то вопрос. Пиши на том что есть, если будет не хватать - тогда и подумаешь.

что реализации vector-а STL медленные все,

угу. Они все копируют поэлементно, что для POD не нужно в 95% случаев.

где-то на хабре читал мнение (правда, от сишника), что реализации vector-а STL медленные все, в принципе. мне нужно для POD, а там возможны оптимизации за счёт realloc. да и malloc с calloc на 5 копеек быстрее вызываются, чем new/delete.

Выкатывай юзкейс - пиши бенч. С меня так уж и быть эталонная и самая быстрая реализация. Сравним.

поскольку контейнеры одинаковые по сути реализованы везде почти

Ололо. С implicit data sharing в Qt, ваш stl отсасывает в полёте..

Ололо. С implicit data sharing в Qt, ваш stl отсасывает в полёте..

CoW не нужен

Авторитетно, чо.

спорно.

спорно.

Компилятор обычно в состоянии оптимизировать лишние копирования при возврате контейнера из функции, а для всего остального есть смарт-поинтеры, Rvalue-ссылки и std::move

Ты ненужнее.

Ты ненужнее.

Пора вырастать из Qt-штанишек, дружок

С implicit data sharing в Qt,

Не такая и однозначная штука. Дополнительный оверхед всегда, а плюсы этой фигни требуются не каждый раз. А когда требуются, то (в 99%) случаев, можно другими средствами обойтись.

ваш stl отсасывает в полёте..

Тупо.

Дополнительный оверхед всегда,

Дополнительный оверхед, это когде нужно пользоваться костылями. Пользоваться Qt контейнерами просто удобнее.

ваш stl отсасывает в полёте.. Тупо.

Я так и сказал, тупо отсасывает.

Пора вырастать из Qt-штанишек, дружок

В скобочки лиспа? Проверь, ты домашку сделал на сегодня?

Странно сравнивать две концепции, преследующие различные цели. CoW расшаривает ресурс между несколькими объектами до момента изменения, тогда как move-semantics предполагает единоличное владение в конкретный момент времени, что полезно для многопоточного кода.

Так давай выключим моск и будем полгаться на компилятор во всём. На вот, почитай на досуге http://stackoverflow.com/questions/1668259/stl-or-qt-containers

Ты неадекватен.

И что не нравится в твоей ссылке?

В свое время implicit data sharing был добавлен в Qt исключительно для оптимизации копирования. В C++11 это неактуально, причем без потери удобства в сравнении с Qt-контейнерами

Я вполне представляю себе как работают контейнеры в Qt, какие у них преимущества и недостатки. Ты торопишься с выводами о собеседниках. К слову, топик 2009-го года

Не туда написал, я нигде не делал никаких выводов.

Я про твою нубскую ссылку

От тебя не увидел ни одной. Безусловно, у всех контейнеров есть преимущества и недостатки. Тот же std::list::splice очень интересен.
Но как я уже заметил, у меня не было выводов о собеседниках, поэтому ты несёшь ахинею.

У тебя папа что ли в Digia работает? Как-то ты болезненно на Qt'шные темы реагируешь. Я лишь заметил, что CoW в Qt неактуален сегодня - в контексте C++11

выше по треду мне уже поставили диагноз.. =)

CoW в Qt неактуален сегодня - в контексте C++11

Чем тут поможет С++11?

QByteArray ba = source;
if(encoded) decode( ba );

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

decode(const NotQByteArray& ba); ?

http://codepad.org/xeFvAl4Q

Теперь замени string на list.

И каким боком тут list? или ты тоже думаешь, что QList это тоже самое, что std::list?

В Qtовских можно пометить, что тип POD и он будет копироваться через memcpy.

используй vector из stl и оставь этот вопрос на будущее иначе у тебя прематур оптимизация такс сказать.

но есть нюанс: когда будущее наступит, как исправлять?

stl::future и прочий async

петросян.jpg

KISS

где контейнерные классы (vector,list, set, и пр.) лучше оптимизированы

у тебя, под твою задачу.

(да, я понимаю, что в 95% так делать не нужно)

CoW не нужен

ты-бы залогинился, я-бы тебе в коммент это вписал.