Девелопмент тулз

Архив

Эпоха DOS миновала безвозвратно, что одновременно и радует, и огорчает. Писать под DOS было проще простого. По словам гуру Windows-программирования Чарлза Петзолда: "Простейший в DOS обучающий пример программы, выводящей на экран содержимое файла, в Windows превращается в монстра". После DOS овладеть программированием под Windows довольно трудно. Но еще труднее научиться программировать сразу под Windows. Слишком многое приходится принимать таким, как оно есть, и втискивать в прокрустово ложе модели программирования. Разумеется, это относится к программированию под "голым" API, без использования библиотек высокого уровня (здесь "втискивать" приходится уже в прокрустово ложе библиотек). Писать под API нужно, чтобы действительно глубоко понять, как все работает. И не тешьте себя иллюзией, что вам это не понадобится. Чем раньше вы поймете обратное, тем лучше.

Итак, была сказана ключевая фраза: "библиотеки высокого уровня". Так уж повелось, что с каждым годом программы становятся все сложнее и сложнее, обретают новую функциональность, поддерживают все больше стандартов. Для программиста это оборачивается кошмаром - ведь ему нужно следить за всеми изменениями, которые Microsoft вносит в Windows. К тому же стандартный подход к программированию в этой среде, а именно чистый C, простым не назовешь. Чтобы в этом убедиться, откройте где-нибудь на середине книгу "Программирование для Windows 95" Чарлза Петзолда, где этот подход изложен in all its best. Достаточно сказать, что лишь Security API в Windows NT насчитывает около четырехсот различных функций. Держать это все в голове не смог бы никто, поэтому естественной выглядит попытка ряда компаний облегчить себе и людям жизнь, написав на объектно-ориентированных языках нечто, позволяющее скрыть хотя бы часть сложности Windows. На сегодняшний день существуют три такие стандартные библиотеки плюс минимум три нестандартных. Стандартом стали (в порядке возрастания удобства и "свежести"): Object Windows Library (OWL, явно устарела), Microsoft Foundation Classes (MFC) и Visual Component Libraries (VCL). Пока еще не стали и, возможно, не станут стандартом Virtual Windows Class Library (VWCL), vxWindows и Qt. Распределение игроков на рынке библиотек таково: OWL и VCL - продукты фирмы Borland, MFC - Microsoft, Qt - норвежской Troll Tech, оставшиеся две созданы community. Qt и vxWindows являются кросс-платформенными. Из всех рассмотренных самой дружественной и простой является VCL.

Как правило, библиотеками высокого уровня фирмы-производители интегральных сред разработки (Integrated Development Environment, IDE) не ограничиваются, внося "исправления и дополнения" в компиляторы и языки. Это приводит к тому, что, например MFC для Borland C++ и MFC для Microsoft Visual C++ - не одно и то же. Так, Borland приходится вносить изменения в MFC, чтобы сделать ее пригодной для своих компиляторов. Последние же нововведения Borland делают программы, написанные на C++ Builder, и вовсе не портируемыми никуда, кроме C++ Builder. Таким образом, рассматривать одно (библиотеки) в отрыве от другого (IDE и компиляторов) бессмысленно, поэтому я позволю себе краткий экскурс в историю того и другого одновременно, но не в хронологическом порядке, а в том, в каком они попадались мне в руки.

Первыми мне попались тогда еще шестнадцатибитные Borland C++ for Windows и Borland Pascal. Не обладая, естественно, RAD-возможностями, они тем не менее позволяли писать под Windows в удобоваримой манере, не опускаясь до Windows API практически нигде. Эти "шедевры" использовали версии С++ и Pascal одной и той же библиотеки классов, OWL, и предлагали свой набор элементов управления. Hа деле же это требовало распространения с готовой программой дополнительных библиотек и приводило к снижению скорости выполнения программ, активно использующих интерфейс. Зато красоты были "неописуемые". Кнопки с картинками, "точеные" диалоговые окна, линии, углубления, чекбоксы... Среда разработки была хоть и удобной, но не визуальной, да Borland на это и не претендовала. Претендовала и претендует Microsoft, но об этом чуть ниже. Программ, использующих все благолепие OWL, было довольно мало, что, учитывая любовь наших разработчиков к продуктам Borland и наличие хорошей литературы, весьма странно. Больше было написано даже под TurboVision - объектно-ориентированную библиотеку для программирования оконных интерфейсов в текстовом режиме DOS. Хорошие примеры - DOS-версии антивирусов Касперского и DOS Navigator. Стоит отметить, что OWL живет и здравствует по сей день, как и традиционный Borland C++, дошедший уже до пятой с хвостиком версии.

Далее была Visual C++ 4. Тут даже исторического экскурса не надо - никаких революционных изменений она с тех пор и по нынешнюю, шестую, версию не претерпела. Казалось бы, компания, разрабатывающая операционную систему, может создать для нее недосягаемо удобные средства разработки. Ан нет. Несмотря на эпитет "visual", визуальность VC++ ограничивается лишь простеньким GUI builder и средствами автоматизации связывания результатов его работы с кодом. Стандартное средство "облегчения" труда программиста в VC++ - Microsoft Foundation Classes. Эта библиотека довольно удобна для построения абсолютно стандартных приложений типа SDI и MDI и приложений, основанных на диалоге (dialog based). Если вам нужно реализовать что-нибудь нетрадиционное, скажем, сделать так, чтобы у окна диалога изменялся размер, приходится пускаться в "пляски с бубном". Так же обстоят дела с dockable-окнами, которыми так соблазняет среда разработки, и "офисовскими" панелями инструментов. Так что же вы приобретаете взамен? Взамен у вас есть некая стандартная базовая функциональность, для обеспечения которой не надо делать вообще ничего: список N последних открытых файлов, автоматическая печать и просмотр печати (print preview) при использовании стандартных классов отображения MFC, стандартная (в смысле "не плоская, открепляемая" либо "плоская", но "неоткрепляемая") панель инструментов, строка статуса, поддержка ActiveX controls, баз данных и Automation. Как уже было сказано, все эти функции почти не изменились с 4-й версии Visual C++. Справедливости ради следует отметить, что MFC поставляет не только компания Microsoft. Библиотеку лицензировали Borland, Symantec, Metrowerks и Watcom. Так что MFC можно считать де-факто стандартом в Windows-программировании. Как ни удивительно, не придерживается этого стандарта, похоже, только сама Microsoft. Если посмотреть, с помощью каких классов сделан, например, MS Word, станет видно, что ничего общего с MFC он не имеет. Как и Excel, и Access, и даже IE. Видимо, программисты из Microsoft и сами считают, что MFC недостаточно хороша для более или менее нестандартных задач.

На момент появления Visual C++ 4 у программистов, по сути, не было большого выбора. Либо MFC, либо OWL, причем преимущество одной перед другой было неочевидным. Именно в тот, не побоюсь этого слова, судьбоносный момент Borland сделала "ход конем", привнеся в Windows-программирование визуальность и компонентность и выпустив свою Delphi 1.0 (шестнадцатибитную) вкупе с библиотекой визуальных компонентов VCL. Поначалу многие восприняли Delphi 1.0 как еще одну среду разработки баз данных, уж слишком похожи были все эти two-way tools на своих близнецов из dBase. На деле же все оказалось не совсем так. Хотя Delphi и была довольно мощной средой разработки БД-приложений, никаких препятствий к ее использованию в качестве универсальной среды не существовало. Не существует их, разумеется, и по сей день, несмотря на распространенное заблуждение. Единственным препятствием к использованию для интересующих меня задач [1] было то, что Delphi базировалась на Object Pascal, объектная модель которого, несмотря на то, что она практически идеальна для бизнес-разработки, мне не подходила. Финансовые дела у Borland в тот момент шли особенно плохо, и многие "аналитики" предрекали фирме скорый конец и установление на рынке безраздельного господства Microsoft с ее MFC. Этого, к счастью, не случилось. Случилось же то, что позволило мне отказаться разом и от MFC- и от API-программирования: вышел Borland C++ Builder, компонентно-совместимая с Delphi RAD-среда (Rapid Application Development), использующая ту же самую библиотеку VCL и обладающая одним немаловажным достоинством: языком был C++.

День сегодняшний балует нас разнообразием и изобилием средств разработки, а также отсутствием ярко выраженного лидера. Удержавшимся на рынке игрокам и будет посвящена оставшаяся часть статьи.

Delphi

Последняя на сегодняшний день версия - 5.0. Delphi является мощным и универсальным средством разработки приложений, RAD-оболочкой. Ее вместе с библиотекой VCL, на которой оболочка основана и написана (да-да, Delphi написана на Delphi), можно назвать действительно революционной. Сравнение с C++ Builder 4 показывает, что производительность Pascal-кода, сгенерированного Delphi, всего на 4-5% меньше, чем кода C++. Метод тестирования был следующим: я перевел на Object Pascal собственноручно написанный экспериментальный трассировщик лучей и выполнил рендеринг ряда тестовых сцен разной сложности. Полученный результат иначе как поразительным не назовешь, ибо считается, что компиляторы Pascal генерируют гораздо худший объектный код, нежели компиляторы C++. Мало того, исполняемый файл был меньше почти на 100 Кбайт. Итак, рассмотрим преимущества и недостатки Delphi.

Возможности

Если кратко - может все. Конечно, Object Pascal накладывает определенные ограничения, но для тех вещей, для которых ее писали, Delphi подходит практически оптимально. Из понравившихся (но, разумеется, нестандартных) "улучшений", внесенных Borland в Object Pascal, хотелось бы выделить свойства (properties) и перегружаемость процедур и функций (overloading). Определенные неудобства при работе с низкоуровневыми функциями API может вызвать то, что стандартным языком для API все же является С, и именно на нем пишутся все новые Software Development Kit (SDK) и заголовочные файлы к ним. Это ни в коем случае не означает, что вы не сможете работать с новыми SDK, просто вам придется написать несложный (но, возможно, объемный) код на Pascal, в котором определить интерфейсы данного SDK. Не поленитесь, однако, поискать на серверах, посвященных Delphi. Очень может быть, что эту работу кто-то уже сделал.

Достоинства

Простота, скорость и эффективность Delphi объясняют ее популярность. Delphi имеет один из самых быстрых компиляторов, порождающий, тем не менее, весьма и весьма неплохой объектный код. Есть и другие достоинства: простота изучения Object Pascal; облегчающие жизнь нововведения - вроде свойств (properties); программы, написанные на Delphi, не требуется снабжать дополнительными библиотеками (в отличие от связки C++/MFC). В самом деле, VCL предоставляет удобный, легко расширяемый объектно-ориентированный интерфейс к Windows, что ни в коей мере не мешает программисту опускаться в самые глубины Windows API. Создателям оригинальных компонентов это приходится делать довольно часто, в отличие от "просто программистов". Как было сказано выше, модель программирования в Delphi - компонентная, что позволяет пользоваться компонентами, написанными другими разработчиками, даже не имея их исходного кода и уж подавно не изучая его. В Интернете есть огромное количество компонентов, значительная часть которых распространяется бесплатно. Применение компонентной модели приводит к тому, что довольно многое в поведении объектов программировать не нужно вообще, и многое, на что в других средах ушли бы недели, можно сделать за часы или даже минуты. Оно и понятно - это ведь RAD-среда. К достоинствам можно отнести очень быстрый браузер классов и мгновенный вывод подсказки автозавершения кода (code completion). Если кратко - может все. Конечно, Object Pascal накладывает определенные ограничения, но для тех вещей, для которых ее писали, Delphi подходит практически оптимально. Из понравившихся (но, разумеется, нестандартных) "улучшений", внесенных Borland в Object Pascal, хотелось бы выделить свойства (properties) и перегружаемость процедур и функций (overloading). Определенные неудобства при работе с низкоуровневыми функциями API может вызвать то, что стандартным языком для API все же является С, и именно на нем пишутся все новые Software Development Kit (SDK) и заголовочные файлы к ним. Это ни в коем случае не означает, что вы не сможете работать с новыми SDK, просто вам придется написать несложный (но, возможно, объемный) код на Pascal, в котором определить интерфейсы данного SDK. Не поленитесь, однако, поискать на серверах, посвященных Delphi. Очень может быть, что эту работу кто-то уже сделал.

Недостатки

Их мало, но они есть. Главный, на мой взгляд, недостаток (и одновременно достоинство) - статическое присоединение (linking) библиотеки VCL и компонентов к исполняемому файлу. Справедливости ради надо сказать, что VCL можно линковать и динамически, но тогда с каждым своим приложением вам придется распространять еще и VCL, а это более 3 Мбайт. Однако если не увлекаться интерфейсными "наворотами" и использовать в программе минимально необходимое число компонентов, то исполняемый файл будет невелик. Другой недостаток (и опять же достоинство) состоит в том, что в используемой в Delphi парадигме форм (Forms) вся информация о форме, включая свойства, настройки компонентов, значения по умолчанию, хранится в exe-файле, причем не оптимальным образом. Анализ исходного кода VCL показывает, что при создании формы фактически происходит чуть ли не синтаксический разбор данных инициализации, что не может ее не замедлять. Третий недостаток, который кто-нибудь тоже может назвать достоинством, - это Object Pascal. Несмотря на простоту, эффективность и легкость в изучении, ему не хватает очень многих мощных средств C++. Мне, например, не достает шаблонов, перегрузки операторов и объектной модели, похожей на объектную модель C++ [2]. Разочаровала Delphi и малым числом параметров оптимизации кода. Кроме того, заметна тенденция к "разрастанию" exe-файлов, генерируемых Delphi. Так, большинство небольших проектов, разработанных в Delphi 4, при перекомпиляции в Delphi 5 "растолстели" на 40-70 Кбайт, при этом, разумеется, не обретя новой функциональности.

Примеры приложений

Прекрасный во всех отношениях FTP-клиент LeechFTP, программа просмотра графических файлов PicView, среда работы с TeX/LaTeX WinEdt - это лишь те программы, которыми я регулярно и с удовольствием пользуюсь. Наверняка есть множество других. Кроме того, по каждому подвернувшемуся случаю пишу программы для решения практических задач. Программировать в Delphi быстро и легко.

C++ Builder

Некий "гибрид" Delphi и C++, о чем говорит хотя бы то, что C++ Builder использует ту же библиотеку VCL, что и Delphi, причем написанную на Delphi. В свете этого логичной выглядит совместимость C++ Builder с Delphi на уровне компонентов и исходного кода. Да-да, С++ Builder может компилировать модули Delphi и работать с довольно большим числом ее компонентов. В то же время C++ Builder - полноценная среда разработки на C++, поддерживающая помимо VCL еще MFC и OWL [3].

Возможности

Позволяет легко и просто разрабатывать все, что угодно, начиная от баз данных и quick solutions и заканчивая научными приложениями. C++ есть C++. Как уже было сказано, может поддерживать разработку с использованием MFC и OWL, однако Borland все сделала для того, чтобы вы сами не захотели разрабатывать свои приложения с помощью этих библиотек и портировали свой код под VCL. Что в силу ее логичности далеко не так сложно, как могло бы быть. Конечно, можно работать и с ActiveX, и даже создавать компоненты ActiveX, но делать их предлагается из компонентов VCL, причем для самодостаточности свежеиспеченных компонентов С++ Builder присоединяет к ним нужный код VCL, что делает их размеры нечеловеческими. Так что здесь по-прежнему не существует (известных мне) альтернатив ATL из Microsoft Visual C++.

Достоинства

Те же, что и в Delphi, плюс те, что обусловлены преимуществами С++ как языка. Прежде всего это гораздо лучшая, нежели в Object Pascal, объектная модель, о которую тем не менее многие ломают зубы, ведь здесь все не так просто, как в OP. Поддержка шаблонов позволяет "на лету" определять, например, списки, очереди, стеки, динамические вектора и хэш-таблицы и т. п. для объектов [4], причем обладающие достаточной "разумностью", чтобы не заставлять программиста писать каждый раз новый код. Есть в C++ и директивы препроцессора, дающие гораздо лучшие возможности управления кодом и создания custom builds. Богатые возможности определения собственных типов данных: после того как вы определили новый тип и операции над ним, он ничем не отличается от встроенных типов, таких как, например, double. Впрочем, за информацией о преимуществах C++ лучше обратиться к специальным изданиям. Что же касается C++ Builder, то в нем набор параметров оптимизации кода также богаче, нежели у Delphi.

Недостатки

Главным недостатком, на мой взгляд, является то, что VCL написана не на C++. Думаю, именно этим вызван увеличенный по сравнению с Delphi размер исполняемых файлов, ведь фактически линкеру приходится присоединять к exe-файлу как библиотеки Delphi (ибо VCL без них работать не может), так и C/C++ - без них все пляски вокруг C++ теряют смысл. Слава богу, речь идет о библиотеках "нижнего уровня", в противном случае все было бы куда хуже. Я, однако, обнаружил, что многие готовы "платить эту цену" за возможность сосредоточиться на своей задаче, а не на "интерфейсных делах", отнимающих море времени и сил у MFC- и API-программистов. Набросал мышкой интерфейс, задал логику его реакции на события, поправил не понравившиеся компоненты и все, можешь писать свой "внутренний" код. Читать хелп почти не придется, все просто, логично и разумно. Однако мысль, что файл стал на 100 Кбайт больше, все же не дает покоя. Не дают покоя и недоделанный браузер классов, и безумно долгое время реакции при выводе подсказки code completion, выводе места определения функции или класса в исходном коде (tooltip symbol insight). Но без этих "излишеств", хорошо реализованных в Microsoft Visual Studio, можно обойтись. Еще один недостаток, сдерживающий серьезные команды разработчиков, - туманное будущее C++ Builder. Традиционно более "сырой" и выходящий гораздо позже очередных версий Delphi, он явно не стоит в списке приоритетных продуктов компании. О чем PR-менеджеры Inprise молчат, как партизаны. Будет ли когда-нибудь выпущена следующая версия C++ Builder? Будет ли она портирована на, скажем, Itanium? Информации по этим вопросам у разработчиков нет. Кроме того, компонентов, написанных под C++ Builder, довольно мало, что обусловлено скорее всего сложностью C++ для изучения.

Приложения

Кроме тех, что указаны в success stories на сайте Inprise, и своих собственных, о приложениях, созданных с помощью C++ Builder, мне не известно. Тем не менее они наверняка есть, ибо со стороны Borland для этого созданы все предпосылки.

Microsoft Visual C++

Труднее всего мне рассуждать о Microsoft Visual C++. И не потому, что она плохо мне известна. А потому, что эта безусловно достойная среда вызывает далеко не однозначную реакцию. И преимуществ, и недостатков тут полно, и порой задумываешься над тем, чего больше. Прежде всего, среда далеко не визуальна. Мало того, что с помощью библиотеки классов MFC, входящей в MS VC++ в качестве основной, программировать под Windows нередко сложнее, чем вообще без нее [5], так еще и приходится распространять MFC с каждой программой [6]. Просто чтобы быть уверенным, что на машине пользователя стоит нужная версия. Это тем более обидно потому, что нужная версия наверняка стоит. Однако хелп! Какой хелп! Ничего подобного нигде и никогда мне видеть не доводилось. А вам доводилось видеть хелп размером более гигабайта? А хорошо написанный и структурированный хелп таких размеров? Так вот, все это есть в MS VC++. Если вы чего-то не знаете о Windows - будьте уверены, там вы это найдете. Впрочем, help (он же Microsoft Developer Network - MSDN) доступен и отдельно. Более или менее серьезному Windows-разработчику обойтись без него все равно не удастся, поэтому придется заплатить дополнительные (и немалые) деньги.

Возможности

Возможно абсолютно все. Возьмите любую технологию Microsoft, и можете быть уверены - для Visual C++ уже есть соответствующий SDK. У MFC/API-программистов отваливается челюсть, когда они впервые видят, что то, что они с таким трудом неделями и месяцами делают "вручную", в Delphi/Builder делается за минуты/часы и мышкой, причем нередко даже без написания кода. Есть еще и параноидальный, но все же веский резон. Если вы собираетесь оставаться на рынке ПО для Windows всерьез и надолго, то можете быть уверены - пока есть Windows, будет и Visual C++. Чего нельзя сказать о продуктах Inprise, финансовые дела которой идут неважно. Впрочем, грамотным подходом я могу назвать лишь написание приложений, не слишком жестко привязанных к той или иной библиотеке классов. MS VC++ подойдет вам и в том случае, если вы собираетесь создавать ActiveX компоненты, так как использование ATL позволяет минимизировать overhead. Есть в MS VC++ и кросс-платформные средства. Так, вам мало что понадобится изменить в коде, если вы захотите портировать свою программу под версию NT для Compaq Alpha. И не так уж много, если на Macintosh [7]. Возможна разработка web-приложений, сервисов NT, dll и статических библиотек, консольных приложений.

Преимущества

Главным преимуществом MS VC++, безусловно, являются ее ничем не ограниченные в рамках Windows возможности. Второе немаловажное преимущество - очень и очень приличный, хотя и довольно медленный компилятор C++. Третье - довольно сносная среда разработки. Четвертое - отличный отладчик, одним из главных преимуществ которого является правка кода в режиме отладки и последующее его выполнение без полной перекомпиляции и прерывания отладочной сессии. Ну и далее без счета: IntelliSense (аналог CodeCompletion в продуктах Inprise) - технология подсказок, работающая быстрее, чем вы думаете, - позволяет делать минимум втрое меньше досадных опечаток. Полноценный браузер классов (и не только), работающий по мере написания вами кода. Причем вы можете группировать классы в браузере по папкам и подпапкам по собственному усмотрению. Столь же полноценный менеджер исходного кода, отображающий файлы и папки так, как вы хотите. Из преимуществ, прямо влияющих на конечный продукт, можно выделить Delay Load Imports - отложенную загрузку динамических библиотек по мере их надобности, средства для работы с базами данных (а в Enterprise-версии - и для моделирования оных), средства контроля производительности приложения.

Недостатки

Сложность. Один из разработчиков сказал, что MFC напоминает ему "гигантскую книгу дурацких правил". Беру на себя смелость утверждать, что так оно и есть. К причудливой мысли "архитекторов" из Microsoft привыкнуть непросто (хотя и вполне возможно). Прежде всего раздражает необходимость запоминания методов работы с каждым объектом, а также довольно длинных и абсолютно непроизносимых аббревиатур. Это вам не Delphi и не C++ Builder, где все "лежит на поверхности". Здесь придется крепко почитать хелп и книжки, прежде чем у вас заработает хоть что-то кроме скелетного приложения. Благо книжек напечатано и переведено до безобразия много. Однако память (вашу, а не компьютера, конечно) всем этим перегрузить довольно легко. Тем не менее писать хорошие программы можно, чему примеров масса. Еще разочаровывает сильная урезанность базовой версии VC++ на уровне компилятора - он не оптимизирующий. К тому же Delay Load Imports она не поддерживает. Если отсутствие типичных Enterprise-средств можно понять, то отсутствие оптимизации - отнюдь. Впрочем, более или менее серьезному разработчику все равно понадобится версия Professional, а Standard предназначена скорее для обучения.

Примеры приложений

Известны всем и каждому. Word, Excel, Internet Explorer написаны, судя по всему, без использования MFC. ReGet, GetRight, ICQ - с использованием. FrontPage 2000 представляет собой пример гибридного подхода. MDI-окна там взяты из MFC, а панели инструментов и меню - из Office [8].

Окончание следует

---

1 (обратно к тексту) - Научное программирование, включая обработку статистических данных, визуализацию, работу с многомерными векторами и матрицами.

2 (обратно к тексту) - Особенно конструкции объектов при объявлении их экземпляров. В Delphi вы можете объявить только ссылку на объект, а уже потом сконструировать и проинициализировать его, вызвав конструктор. В случае больших классов это нетрудно. Но если в вашей программе есть, скажем, массив векторов, это может быть утомительно. К тому же их потом надо уничтожать, вызывая метод Free. Если этого не сделать, они будут оставаться в памяти до завершения программы. В C++ объекты уничтожаются по выходу из зоны видимости.

3 (обратно к тексту) - Хотя и довольно криво.

4 (обратно к тексту) - А не ссылок на объекты, что важно. Хотя можно создать указанные структуры и для ссылочных типов.

5 (обратно к тексту) - О программировании без MFC см. www.relisoft.com. Очень толковый сайт. Однако разработчику-одиночке такой стиль вряд ли подойдет. Так, например, разделяемые окна (split windows), да и много чего еще придется делать от и до руками, а это отнюдь не тривиально.

6 (обратно к тексту) - Либо присоединять статически, но этим устраняется ее последнее преимущество над VCL - то, что она на момент запуска вашей программы почти наверняка уже есть в памяти и совместно используется приложениями.

7 (обратно к тексту) - Во всяком случае, это декларируется.

8 (обратно к тексту) - Вся информация о "родословной" получена с помощью Microsoft Spy++.