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?
Ответ
Лично мое мнение - вопрос надуманный, поскольку концепция 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 и
Комментариев нет:
Отправить комментарий