Записки программиста

Некоторое время назад я стал интересоваться разработкой кроссплатформенных GUI приложений. Сейчас существует множество подходов к разработке данного типа программ — это Java, библиотеки GTK и Qt, скриптовые языки. Однако я сделал выбор в пользу библиотеки wxWidgets, и ниже будет рассказано, почему.

1. Зачем вообще все это нужно

Любого программиста рано или поздно посещают следующие мысли. Вот было бы здорово написать приложение один раз и чтобы оно могло работать под Windows, Linux, MacOS, FreeBSD и вообще любой операционкой безо всяких патчей и доработок. А вот помню, как легко и просто было создавать GUI приложения в Borland Delphi. Кажется, это еще называется RAD — Rapid Application Development. Почему в моей IDE такого нет? И еще в последнее время почему-то очень много говорят о Java и C#, дескать там нет утечек памяти, зато есть юникод, регулярные выражения, кроссплатформенные треды, и много других полезностей прямо из коробки. Надо бы завязывать с C++…

Так начались мои поиски универсального средства, позволяющего быстро создавать кроссплатформенные GUI приложения, а также дающего умные указатели, юникод, регулярные выражения, интернационализацию и тп.

2. Чем плохи Qt/Python/Java/…

После продолжительного серфинга в поисках ответа, я сделал выбор в пользу wxWidgets. В этом разделе я решил перечислить причины, по которым были отвергнуты Python, C#, GTK и прочие решения. Если вас этот вопрос не интересует, смело переходите к следующему разделу.

Библиотека QT позволяет быстро создавать кроссплатформенные GUI приложения, но имеет множество недостатков. В первую очередь к ним относится неясная ситуация с перспективами развития проекта. Дело в том, что недавно Nokia продала Кьют какой-то непонятной компании Digia. Связываться с потенциально мертвым проектом мне не хочется. Также Кьют небезосновательно критикуют за высокое потребление ресурсов и большой размер создаваемых с его помощью программ.

GTK имеет меньше недостатков, но также не безупречен. GTK-приложения, скомпилированные под Windows, также много весят (при статической линковке) или требует предварительной установки GTK библиотек (при динамической линкове). Еще один существенный недостаток GTK — он использует «неродные» элементы управления. То есть GUI приложение, написанное на GTK, под Виндой выглядит немного не так, как все остальные Windows-приложения. Вам это может показаться несущественным, но у рядового пользователя вид кнопки с закругленными углами вместо привычных острых углов вызывает паническую атаку и моментальный разрыв связи с реальностью. Вспомните, как большинство людей плюются от Gimp и OpenOffice, дескать непривычно. Или как неудобно первые пару дней пользоваться Windows 7 после нескольких лет использования Windows XP.

Вокруг Java ситуация неоднозначная. Со слов одних разработчиков, Java — это наше все. Другие удивляются, что Java еще жива. Я постарался посмотреть на ситуацию объективно и увидел следующее. Во-первых, известно, что приложения на Java работают в 1,5-2 раза медленнее приложений на C++. Вы согласны, чтобы ваш компьютер работал в 2 раза медленнее ради удобства программистов? Я — нет. Во-вторых, выяснилось, что хваленный Garbage Collector не только решает проблемы, но и создает новые. В частности, с работой GC связывают периодическое подвисание мобильных устройств, работающих на Symbian и Android. Также Java не лишена проблемы с нестандартными контролами.

Когда-то Sun (будучи тогда еще автономной компанией) строила грандиозные планы по захвату мира с помощью Java. Дескать все устройства от телевизионных пультов и микроволновок до DVD-плееров и мобильных телефонов будут иметь ПО, написанное на Java, а также взаимодействовать между собой с помощью одного протокола. Дескать Java-апплеты будут чуть ли не популярнее формата GIF.

Что получилось на практике? Апплеты оказались никому ненужными (за всю жизнь я на них натыкался от силы раза три). Среди десктоп-приложений Джаву сильно потеснил C#. Главным образом, за счет того, что технология .NET идет в комплекте с Windows, в то время, как Java еще нужно скачивать и устанавливать. Была надежда, что Java приживется на мобильных устройствах, но она умерла вместе с отказом Nokia от дальнейшего использования Symbian в пользу Windows Phone. Фактически, Java более-менее активно используется только на Android (и то, под него можно писать на C++) да под UNIX (куда, благодаря проекту Mono, активно проникает C#).

Дополнение: Недавно Java была исключена из Linux Standard Base. Выходит, даже в мире UNIX ей не рады.

.NET (C#, F#, VB.NET) видится мне намного привлекательнее Джавы. За счет поддержки технологии .NET Microsoft’ом, разработчики имеют гарантированную клиентскую базу в лице пользователей Windows и Windows Phone. Напоминаю, что последний теперь будет устанавливаться на всех телефонах Nokia. Таким образом, Windows Phone в скором времени будет стоять чуть ли не на каждом втором мобильном устройстве (39% рынка у Nokia и 9% у Microsoft). О том, что Windows установлен на 90% персональных компьютеров, думаю, напоминать не стоит. Из недостатков ДотНет имеет только низкую (но в большинстве случаев приемлемую) производительность, проблемы, присущие GC, а также не совсем полную совместимость с UNIX’ами.

Python/Ruby и вообще скриптовые языки были отвергнуты в связи с проблемами переносимости (пользователи Windows вынуждены скачивать и устанавливать интерпретаторы) и низкой производительностью. Тем не менее, мое внимание привлек проект Cython (транслятор языка Python в код на C). Возможности тут очень интересные — от использования Python в программах на C/C++ до полной компиляции Python-скриптов в исполняемые файлы и, как следствие, решение проблемы с производительностью и переносимостью. Но этот вопрос еще предстоит как следует провентилировать.

И напоследок хотелось бы упомянуть проект Lazarus. Это — попытка создать кроссплатформенную RAD-IDE на основе Free Pascal. Фактически — клон Borland Delphi, бесплатный и способный создавать легко переносимые приложения. Насколько я могу судить, клон этот более, чем успешный. Я не имею каких-либо предрассудков в отношении Pascal, но будучи человеком, испорченным C-подобными языками, работать с Lazarus мне не комфортно. Учитывая, сколько людей пишут на Delphi, и тот факт, что в большинстве школ обучение программированию начинают с Pascal, эта IDE без труда найдет своих почитателей.

3. Возможности wxWidgets и Code::Blocks

Сначала, давайте выясним, who is who. wxWidgets — это фрейморк (библиотека, набор классов — кому как больше нравится) для создания кроссплатформенных приложений. Что-то вроде STL + Boost + GTK в одном флаконе. Code::Blocks — это кроссплатформенная RAD-IDE, заточенная для создания приложений с использованием C++ и wxWidgets. Является далеко не единственной в своем роде, но при этом наиболее популярной. Из особенностей Code::Blocks стоит отметить поддержку плагинов, наличие встроенного редактора пользовательского интерфейса (плагин wxSmith), а также возможность запускать IDE под любой ОС, включая мою любимую FreeBSD.

Что дает нам wxWidgets?

• Переносимость приложения под большинство современных ОС безо всяких изменений;
• Быстрое создание GUI, при этом используются нативные контролы*;
• Умные указатели, кроссплатформенные треды, регулярные выражения, хэши, сериализацию, юникод и интернационализацию;
• Многие другие вкусности, включая HTTP- и FTP-клиенты, парсер XML, классы для работы с БД и даже готовый HTTP-сервер;
• Отсутствие необходимости в предустановке JVM, интерпретатора и тд;
• Относительно небольшой размер скомпилированного приложения, умеренное потребление памяти и тактов процессора;
• Возможность использовать все это не только в C++, но и в Python, Ruby, Perl, Haskell, Erlang и прочих языках;

* «Используются нативные контролы» означает, что при компиляции под Windows приложение будет рисовать GUI с помощью WinAPI, а при компиляции под UNIX — с помощью GTK или, если мы этого захотим, даже на чистом X11. Почему не стоит лишний раз пугать пользователя незнакомыми ему контролами (элементами управления), как это делает Java и Кьют, было рассказано в предыдущем пункте (чисто на случай, если вы вдруг его перепрыгнули). Обратная сторона медали — необходимость проверять, как выглядит интерфейс в каждой системе. К счастью, тут все на три порядка проще, чем в кроссбраузерной верстке.

Разумеется, wxWidgets имеет свои недостатки. Например, при объявлении строк нужно использовать либо макрос _T(), либо _(). Первый — просто для строк в юникоде, второй — для интернационализации. Это несколько напрягает и замедляет скорость кодирования (я уж не говорю о том, что скорость конструирования на C++ всегда существенно меньше, чем на Perl или Python). К счастью, Code::Blocks умеет автоматически подставлять парные скобки и кавычки, так что наши усилия сводятся к минимуму.

Еще один неприятный момент — малое количество тематических блогов, видеоуроков и практически полное отсутствие литературы. К счастью, wxWidgets очень прост в изучении (для меня самым сложным было понять, что в 90% случаев весь лайаут строиться на основе wxBoxSizer), а на официальном сайте приведена исчерпывающая справочная информация. Похоже, что в настоящее время wxWidgets является наименьшим из зол, которое приходится выбирать при кроссплатформенной разработке.

Хочу также отметить, что существуют косвенные признаки возможности разработки с помощью wxWidgets мобильных приложений. Но я в настоящее время мало интересуюсь этой темой, да и ситуация с языками программирования для мобильных устройств сейчас весьма нестабильная.

4. Что дальше?

Начиная писать этот пост, я планировал рассказать об установке Code::Blocks под различными операционными системами (там есть тонкие моменты), а также привести несколько примеров кода. Но пост получился слишком объемным, так что о названных вещах я напишу в одной из следующих заметок. Если у вас есть замечания по поводу написанного или вопросы по wxWidgets, оставляйте их в комментариях, не стесняйтесь. Если вам нужна какая-нибудь программа, можете оставить заявку на ее написание. Возможно, ваша идея покажется мне интересной, и я напишу то, что вам нужно.

Дополнение: В продолжение темы — Примеры использования wxWidgets.

Метки: C/C++, GUI, Кроссплатформенность.