Использование STL и фреймворков в C++

#cpp #boost

C++ 2 главные библотеки (ИМХО): одна стандартная, одна почти стандартная(Boost).
Но ни одна из них не позволяет создавать GUI (с кнопочками, менюшками и т.д.). А потому,
есть и фреймворки: Qt, wxWidgets (MFC не в счет -- он не кроссплатформенен), однако,
оба "переписывают" (дублируют) Stl (QString, wxString и т.д.**; **вариант: компилировать
wxWidgets с использованием stl сами разработчики считают не совсем кошерным, т.к. он,
по умолчанию, не работает). 

Однако, в более-менее большом приложении обязательно будут сторонние библиотеки,
которые используют Stl, да и не обязательно все классы из Stl присутствуют в фреймворке.

Вопросы: что делать с огромным количеством абсолютно бесполезно продублированного
кода? Использовать stl классы или классы, предоставляемые фреймворком?

UPD: Что делать с принципом DRY (Don't Repeat Yourself) или это исключение?

UPD2: Как я понял, классы Qt серьёзно отличаются от аналогов в stl, а значит и DRY
страдает не сильно. Что про wxWidgets? В wxBook написано:


  Классы из wx на 70% похожи на классы из
  Stl


Я думаю, даже больше. А что с ними и DRY? 
    

Ответы

Ответ 1

Лично мое мнение - вопрос надуманный, поскольку концепция DRY (особенно в отношении
контейнеров) намного в меньшей степени применима к устоявшимся фреймворкам, которые
пережили несколько мажорных версий.




Тем более, что, например, если говорить о STL, Qt и Boost, то DRY, за исключением
некоторых моментов, не нарушается. 


Все Qt поддерживают семантику copy-on-write, а иногда вообще не совпадают с контейнерами
STL в плане соответствия названия и назначения (например, std::set и QSet - это совершенно
разные вещи).


boost-specific контейнеры нигде не дублируют функциональность, предоставляемую STL.




На уровне таких проектов решение о реализации своего набора контейнеров может быть
принято чуть ли не исходя из аргументов типа "std::vector плохо смотрится в коде вместе
с QString".


Или, например, если вы подойдете и спросите у девелоперов EASTL, слышали ли они про
DRY и способы уменьшения энтропии в системы, то, мне кажется, вам рассмеются в лицо :)


Количество продублированного кода, как вы это называете, не является проблемой до
тех пор, пока под кодом подразумевается код фреймворка.




Для своих проектов полезно выбрать некоторую стратегию использования контейнеров,
например, используем только QXyz или std::xyz.


Причем понятно, что под использованием здесь имеется ввиду использование в интерфейсах.
На уровне реализаций конкретных интерфейсов можете использовать что угодно и как угодно,
хоть std::vector, написанный на ассемблере. Но протаскивать его вверх по иерархии,
естественно, не стоит - достаточно в местах, где контейнер является частью интерфейса,
осуществить соответствующее преобразование.




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


По своему опыту скажу, что приложение с boost::graph замечательно работает под ARM,
а подключение любого хэдера boost::mpl сравнимо с подключением всех контейнеров Qt
в плане времени компиляции.


На практике, лично с моей точки зрения, 90% промышленных продуктов можно построить,
если использовать Qt (фреймворк вообще и пользуясь только их контейнерами), boost::type_traits
и .


При необходимости также можно strip'ать и добавлять в проект какие-либо части boost
типа boost::graph, boost::flyweight или boost::heap.


Ответ 2

Ну, вообще то, boost и stl - это статик либы. Так что если Вы не будете из них ничего
использовать, и добавляться к получаемому файлу из них не будет. А если вы будете использовать
какой то элемент из буста, к примеру, то к вам добавится он и всё что ему требуется
для функционирования, но всё остальное - нет.