Russian Qt Forum
Ноябрь 06, 2024, 04:45 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Qt vs. STL  (Прочитано 15569 раз)
gueRRero
Гость
« : Апрель 29, 2009, 20:57 »

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

Записан
crackedmind
Гость
« Ответ #1 : Апрель 29, 2009, 21:00 »

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

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

Проверялось все на VC++ 2008 со стандартным STL, с STLport результаты могут быть другими Улыбающийся
« Последнее редактирование: Апрель 29, 2009, 21:03 от crackedmind » Записан
Rcus
Гость
« Ответ #2 : Апрель 29, 2009, 21:31 »

Идеологии контейнеров Qt и STL несколько отличны.
Qt предоставляет максимально богатый интерфейс, копирование контейнера за константное время, но ценой дополнительных проверок при доступе к разделяемым данным (implicit data sharing), но у Qt есть возможность оптимизации через Q_DECLARE_TYPEINFO.
STL предоставляет минимально возможный интерфейс и следует идеологии минимального овердхеда.
Записан
WW
Гость
« Ответ #3 : Апрель 29, 2009, 22:21 »

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

Сообщений: 1988



Просмотр профиля
« Ответ #4 : Апрель 29, 2009, 23:36 »

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

Вывод - если вы хотите настоящую кроссплатформенную прогу - юзайте QT STL. Портируемости будет больше.
Записан
Sergeich
Гость
« Ответ #5 : Апрель 29, 2009, 23:43 »

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

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

Например не одна моя консольная утилита не использует Qt. Улыбающийся

П.С. Насчёт скорости - таки в первую очередь нужно смотреть алгоритмы, а дальше как конкретные структуры реализованы. Улыбающийся
« Последнее редактирование: Апрель 30, 2009, 07:15 от Tonal » Записан
Steven_Orko
Гость
« Ответ #7 : Апрель 30, 2009, 08:54 »

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

Например не одна моя консольная утилита не использует Qt. Улыбающийся

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

Сообщений: 1988



Просмотр профиля
« Ответ #8 : Апрель 30, 2009, 12:32 »

Цели бывают разные - если нужна кросплатформенность, то только Qt. Если пофиг - STL.
Записан
SABROG
Гость
« Ответ #9 : Апрель 30, 2009, 12:47 »

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

Сообщений: 1988



Просмотр профиля
« Ответ #10 : Апрель 30, 2009, 13:07 »

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

Записан
Tonal
Гость
« Ответ #11 : Май 04, 2009, 12:04 »

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

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

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

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

Хотя если нужно быстро набросать что-то не предполагающее дальнейшей поддержки, то конечно в любом месте можно использовать любую структуру/контейнер удовлетворяющий текущим задачам. Улыбающийся
Записан
asinxron
Гость
« Ответ #12 : Февраль 16, 2010, 10:51 »

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

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

Проверялось все на VC++ 2008 со стандартным STL, с STLport результаты могут быть другими Улыбающийся
А можно исходники любых тестов STL и Qt выложить?
Ну или рассказать более подробно какие параметры использовались при тестировании и как например измерить время вставки элметов в вектор?
Записан
Karl-Philipp
Гость
« Ответ #13 : Февраль 16, 2010, 12:00 »

Время заполнения контейнера можно измерить, например, так:
Код
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());
Записан
asinxron
Гость
« Ответ #14 : Февраль 18, 2010, 11:23 »

Спасибо за ответ,но я имел в виду какой-нибудь класс CPU - т.е. использовать его для измерений числа системных тиков на компьютере от его создания до разрушения,ну или по другому без использования бибилиотек STL,Qt и winAPI,чтоб можно было и на линукс скомпилировать.P.S.Был бы оч. благодарен. Непонимающий
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.154 секунд. Запросов: 23.