Russian Qt Forum

Всем доброго времени суток. Я как-то из соображений единостилия обычно в программах, написанных с Qt стараюсь использовать Qt-шные аналоги STL. Вот стало интересно, в чем же между ними принципиальная разница? Что быстрее работает? Кто-нибудь проверял? Что все-таки лучше использовать?
З.Ы.: Меня больше всего интересует QMap и std::map, но хотелось бы узнать и об остальных.

Насчет QMap не скажу, но тестировал QString и std::wstring, QString в 2х тестах из 3 оказался быстрее =) Правда тесты были мега тупые ) В основном на аллокацию памяти.

update
А также QVector чуть медленее, чем std::vector

Проверялось все на VC++ 2008 со стандартным STL, с STLport результаты могут быть другими :)

Идеологии контейнеров Qt и STL несколько отличны.
Qt предоставляет максимально богатый интерфейс, копирование контейнера за константное время, но ценой дополнительных проверок при доступе к разделяемым данным (implicit data sharing), но у Qt есть возможность оптимизации через Q_DECLARE_TYPEINFO.
STL предоставляет минимально возможный интерфейс и следует идеологии минимального овердхеда.

Все зависит от того, что пишешь.
Если пишешь общий модуль, кот. может вызываться не только в Qt-прогах - то лучше стл. Если только конкретную прогу на Qt - то лучше все единообразно (меньше зависимостей).
Где-то так...

В Linux как минимум 2 stl - в gcc и stlport.
В каждом MSVC - своя.
В Builder на выбор кажется 3 штуки

Вывод - если вы хотите настоящую кроссплатформенную прогу - юзайте QT STL. Портируемости будет больше.

Насчет QMap и std::map, STL вариант будет быстрее за счет отсутствия implicit data sharing, например при куче insert или [], так что если СИЛЬНО важна производительность именно при юзании контейнеров без random access - то тут лучше STL. Если контейнер поддерживает random access - то тут однозначно QTL. Повышение производительности при использовании STL-аналогов (не думаю что оно больше 30% в лучшем случае) не окупит удобство работы с QTL, в качестве примера, можно взять, опять же  QString vs std::wstring - последний полностью отсасывает по юзабельности.

Я всегда отдаю предпочтение stl, т.к. она входит в стандарт языка, и никуда из C++ не денется. А на Qt свет клином не сошелся. :)
Использую QTL только для взаимодействия с Qt.

Например не одна моя консольная утилита не использует Qt. :)

П.С. Насчёт скорости - таки в первую очередь нужно смотреть алгоритмы, а дальше как конкретные структуры реализованы. :)

+1
Имхо, наиболее верный подход. Для каждого дела свои инструменты.

Цели бывают разные - если нужна кросплатформенность, то только Qt. Если пофиг - STL.

+1. Сам как-то тестировал скорость std::string и сколько он жрет памяти. Пробовал gcc,bcc,msvc. Сначала на их родных stl тестил, потом на stlport. Результаты были разными и скорость тоже. Поэтому если программы на "стандартном" stl будут по разному себя вести под разными компиляторами и платформами - я не удивлюсь. Не стоит забывать, что каждый понимает и реализовывает стандарт по своему. Т.ч. либо stlport, либо Qt. А ставить stlport для того, чтобы скомпилить Qt приложение я бы пользователей не стал заставлять. Скорее напишу багрепорт в Qt, если пойму почему что-то медленнее, чем родное. Введут какой-нибудь lightweight класс для контейнеров типа QLatin1String.

  Насчет stlport - его насколько помню щас 2 версии 4 и 5 ( давно дело было). Так вот 5 версия у меня так и не собралась MSVC6. Может щас конечно допили, но все же.
  Программа падала в связке gcc+stlport, фиг знает почему, gcc+его родной stl все пучком.

Как-то не очень понятно что значит "...тестировал скорость std::string и сколько он жрет памяти".
В стандарте даны некоторые гарантии по временной сложности отдельных операций и размерам памяти. Если реализация им удовлетворяет - она удовлетворяет стандарту.
Если закладываться именно на это - получишь переносимые программы на С++.

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

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

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

Хотя если нужно быстро набросать что-то не предполагающее дальнейшей поддержки, то конечно в любом месте можно использовать любую структуру/контейнер удовлетворяющий текущим задачам. :)

А можно исходники любых тестов STL и Qt выложить?
Ну или рассказать более подробно какие параметры использовались при тестировании и как например измерить время вставки элметов в вектор?

Время заполнения контейнера можно измерить, например, так:

C++ (Qt)
QVector<int> testVector;
QTime timer;
timer.start();
for(int i = 0; i < maxValue; ++i)
    testVector.append(i);
qDebug("processing time is: %d ms", timer.elapsed());

Спасибо за ответ,но я имел в виду какой-нибудь класс CPU - т.е. использовать его для измерений числа системных тиков на компьютере от его создания до разрушения,ну или по другому без использования бибилиотек STL,Qt и winAPI,чтоб можно было и на линукс скомпилировать.P.S.Был бы оч. благодарен. ???