Qt — инструментарий, связанный с KDE-проектом. Он представляет собой собственную библиотеку С++. Доступны привязки для Python и Perl, но они не поставляются со стандартными интерпретаторами. Qt получил известность благодаря наличию хорошо спроектированного и наиболее выразительного API из всех четырех инструментариев, однако его принятие в начальной стадии было заблокировано полемикой по ранним версиям лицензии и в дальнейшем тормозилось медленным созданием С-привязки.
Инструментарий wxWindows также является естественным для С++ и имеет доступные привязки в Perl и Python. Его разработчики придают особое значение главным образом поддержке кроссплатформенной разработки и рассматривают ее как главную рыночную цель инструментария. Другая цель связана с тем, что wxWindows фактически является упаковщиком для собственных (GTK, Windows и MacOS 9) элементов управления на каждой платформе, а поэтому приложения, написанные с его использованием, имеют естественные для данных систем вид и восприятие.
К середине 2003 года было описано не слишком много подробных исследований, однако Web-поиск фразы "X toolkit comparison" поможет найти некоторые полезные справочные сведения. В табл. 14.2 обобщена информация о состоянии рассмотренной области.
Таблица 14.2. Сравнительные характеристики Х-инструментариев
С++
Tk
Tel
Tel, Python
+
+
+
+
+
GTK
С
Gnome
+
+
+
+
+
Qt
С++
KDE
+
+
+
+
+
wx Windows
С++
-
-
+
+
+
+
Архитектурно все данные библиотеки написаны на почти одном и том же уровне абстракции. В GTK и в Qt используются настолько подобные аппараты для обработки событий, что перенос программ между ними рассматривается как почти тривиальный. Выбор инструментария, вероятно, будет больше обусловлен доступностью привязок к используемому языку разработки, чем любыми другими факторами.
15 Инструментальные средства: тактические приемы разработчика
15.1. Операционная система, дружественная к разработчику
За операционной системой Unix давно закрепилась репутация хорошей среды для разработки программ. Она хорошо оснащена инструментами, написанными программистами для программистов. Данные инструменты автоматизируют многие рутинные мелкие задачи, которые в противном случае отвлекали бы внимание программиста от наиболее важного (и наиболее увлекательного) аспекта разработки — от проектирования.
Несмотря на то, что в Unix есть все необходимые инструменты и каждый из них хорошо документирован, они не связаны с помощью интегрированной среды разработки (Integrated Development Environment — IDE). Их поиск и внедрение в инструментальный набор, удовлетворяющий потребностям разработчика, всегда требовали значительных усилий.
Разработчику, привыкшему к хорошей IDE-среде (GUI-управляемой комбинации редактора, конфигуратора, компилятора и отладчика, которая в наши дни широко распространена в системах Macintosh и Windows), принятый в Unix подход может показаться бессистемным, туманным и примитивным. Однако в действительности он достаточно систематизирован.
Использование IDE имеет смысл для одноязыкового программирования в слабо оснащенной инструментами среде. Если работа программиста ограничена оттачиванием вручную кода на С или С++, то IDE-среды весьма целесообразны. Однако в Unix выбор языков и вариантов реализации гораздо разнообразнее, а практика использования нескольких генераторов кода, специальных конфигураторов и многих других стандартных и нестандартных инструментов является общепринятой.
В Unix действительно существуют IDE-среды (имеется несколько таких сред с открытыми исходными кодами, включая эмуляции основных IDE Macintosh и Windows). Однако с их помощью трудно контролировать неограниченное множество инструментальных средств, и поэтому IDE-среды используются нечасто. Операционная система Unix поддерживает более гибкий стиль, центром которого не является исключительно цикл редактирование/компиляция/отладка.
В данной главе рассматриваются тактические приемы разработки в Unix — создание кода, управление его конфигурацией, профилирование, отладка, а также автоматизация большого количества монотонной работы, связанной с этими задачами, с тем чтобы разработчик мог сконцентрироваться на более увлекательных аспектах. Как обычно, при изложении материала основное внимание в большей степени уделено архитектурной картине, чем пошаговым инструкциям. Если же читатель
