QT vs STL

[malin]

Здравствуйте! Такой вопрос возник в связи с изучением QT.

Недавно узнал, что в QT есть своя библиотека, очень похожая на STL(даже названия схожи - QVector и vector ...). Кроме того, не все QT - шные классы можно засунуть в STL-овские контейнеры.

Теперь вопрос: зачем были придуманы эти QVector, QList, ...., если есть стандартные vector, list, ....?

Второй вопрос: в чём всё-таки следует хорошо разобраться? В STL или в этом "QSTL", если планирую дальнейшее изучение QT?

[Xaositect]

Вот приличная на мой взгляд (я не специалист) ссылка: http://blog.codeimproved.net/2009/12/qtl-or-stl/

[Circiter]

2malin

Цитата:

Теперь вопрос: зачем были придуманы эти QVector, QList, ...., если есть стандартные vector, list, ....?

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

Цитата:

Второй вопрос: в чём всё-таки следует хорошо разобраться? В STL или в этом "QSTL", если планирую дальнейшее изучение QT?

Не помешало бы хорошо разобраться в QTL. Более менее хорошее знание STL и так подразумевается если вы пишите на C++. Т.е., в итоге, придется учить и то и то; ну а что вы хотели.

Вообще, если при разработке проекта планируется широкое использование стандартной библиотеки, использование legacy-кода, или использование кода будущего продукта в других проектах, то основную логику, другими словами большую часть проекта, все-таки лучше писать под STL (хотя бы ради этой самой reusability и поддержки со стороны стандарта). А вот часть проекта, имеющую глубокие зависимости с Qt необходимо писать с использованием QTL, что позволит избежать лишних (и возможно дорогих) преобразований между объектами, предоставляемыми этими все-таки разными библиотеками.

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

Так же, в дополнение к ссылке, приведенной Xaositect'ом, думаю, стоит поискать какое-нибудь rationale в самой Qt-документации.

P.S.: Сам Qt не пользуюсь, изобретаю велосипеды, пока доволен.

[Roman Voznyuk]

malin в сообщении #279511 писал(а):

Второй вопрос: в чём всё-таки следует хорошо разобраться? В STL или в этом "QSTL", если планирую дальнейшее изучение QT?

STL и желательно Boost
QT приходят или уходят вместе с модой(сколько уже было разных за последнее десятилетие), а C++ и стандартные библиотеки остаются

[Xaositect]

Roman Voznyuk в сообщении #281133 писал(а):

QT приходят или уходят вместе с модой(сколько уже было разных за последнее десятилетие)

Одно. В 2002 вышло KDE3, с тех пор Qt - один из двух самых распространенных тулкитов под Linux.
Если что, оно(частично) входит в Linux Standard Base.

[Roman Voznyuk]

Xaositect в сообщении #281148 писал(а):

Одно. В 2002 вышло KDE3, с тех пор Qt - один из двух самых распространенных тулкитов под Linux.
Если что, оно(частично) входит в Linux Standard Base.

Никто с этим не спорит что QT особенно огда оно стало бесплатным на данны момнет является наверное самой удачной переносимой библиотекой для создания GUI, и доля прложений написанных на нем будет тольо увеличиваться.
Но, с другой стороны, никто не может дать гарантии, что не появится что то лучше.
В конце концов этого всего лишь надостройка над C++, который базис.

[Circiter]

Помните как было с MFC?

[malin]

Ё-маё!!! ещё Boost есть! Вот спасибо! там даже функция для решения СЛУ имеется, и набор статистических тестов, которые я месяца 3 писал...
да и вообще математики в ней много..
Спасибо всем за ответы, особенно за boost