Уход от Delfi, на конторе Опции

[SasaVitebsk]

Занимаемся различной электроникой. Сопутствующие програмки для PC до этого писали под Delfi. Понятно, что тема себя изжила.
Подыскиваем новый пакет для дальнейшей деятельности.
RAD студия выглядит как-то оторвано от общего потока.
VS кажется слишком монстрообразной. Текучка программистов значительная и боимся сложностей с поддержкой написанных пакетов.
Скачал и установил QT (QT Creator). Вроде выглядит привлекательно. Поддерживается, развивается. Локализация русская. Много примеров. Форумы. Бесплатная.

Кто поделится своими наблюдениями. Посоветует. Замечания.
Заранее благодарю.

[dxp]

Скачал и установил QT (QT Creator). Вроде выглядит привлекательно. Поддерживается, развивается. Локализация русская. Много примеров. Форумы. Бесплатная.

Кто поделится своими наблюдениями. Посоветует. Замечания.
Заранее благодарю.

Когда-то для разработки софта для РС (для внутренних нужд) пользовался Borland C++Builder. Потом, освоивши Python, многие вещи делал на нём. Но иногда встаёт необходимость именно в полноценном экзешнике с нативно исполняемым кодом. Развитие билдера не понравилось - в отличие от пятёрки, которая была проста, быстра и достаточно стабильна, последние версии выглядят монстроидально, громоздко и мутно.

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

1. Qt - это не RAD система. То, что там есть Designer, не делает его таковой. В отличии от дельфей и билдера, где можно было накидать на форму компонентов (в том числе и неграфических) и быстренько в полувизуальной манере запрограммировать поведение - евенты повесить, задать значение всех свойств по умолчанию и т.п., тут такие номера не проходят. На форму можно положить некоторые виджеты, но по большому счёту этим всё и ограничивается. Т.е. от дизайнера эффективно можно получить только геометрическое размещение виджетов и всё. Остальное - назначение событий, их обработка, инициализация и настройка - всё это делается руками в коде. Это не так удобно как борландовских продуктах, но склонен считать, что это более правильный подход, хотя он и требует глубже вникать в систему и разбираться с её потрохами. Поэтому Appication Development получается не такой уж и Rapid
   
2. Среда разработки Qt Creator (как и почти все среды) весьма отстойна. Да, там многие вещи делаются неплохо, но есть и масса неприятных мелочей, начиная от того, что курсор в редакторе прыгает по тексту при вертикальном перемещении в зависимости от конца строк и заканчивая тем, что нет удобного расположения редактируемых окошек в виде привычных по многим программам табов. Собираюсь со временем перелезть на свой любимый слик. Самое сложное тут - это переделать среду сборки под сконс, избавившись от make и, как следствие, их инструмента организации проекта qmake. Основное тут - это разобраться с moc (meta-object compiler).
   
3. Качество самого фреймворка в целом на высоте. Но отдельные программные его модули оставляют желать лучшего. Например, QtSQL не приходится рассматривать как полноценную библиотеку, целиком пригодную для написания сложных программ. Её слой драйверов и низкоровневого БД API вполне вменяемые, но вот про третий слой - прикладные модули (QSqlTableModel и подобные) этого сказать нельзя. В общем, нужно в каждом случае внимательно смотреть, на каком уровне выполнен прикладной модуль. Мнение обычно можно составить, читая посты на форумах - информации предостаточно. Правда, я сперва набил немного шишек на этом модуле, а потом уже накопал на форумах, что проблема не нова.
   
4. При организации всех классов Qt используется идеология на основе паттерна PImpl (Pointer to Private Implementation). Она имеет свои плюсы и минусы. Главное, для чего они её заюзали - поддержание бинарной совместимости (по крайней мере, в пределах мажорных номеров версий). Правда, мой опыт показал, что это в реале не работает, во всяком случае, не всегда - при переходе с версии 4.6.3 (а под неё мной руками были собраны драйвера для сервера MySQL) на крайнюю версию 4.7.3 программа отказалась вязаться с сервером. Пересборка драйверов порулила проблему.
   Ещё одно преимущество такого подхода - более быстрая загрузка программы. Программа действительно грузится и работает быстро. Но при отладке этот подход доставляет проблемы: несмотря на open source реализация потрохов видна не на всю глубину. И постоянно сталкиваться с кодом Q_D(class_name); и далее d->... - не добавляет комфорта. Разбираться с этим кодом сложнее, чем с написанным явно, т.к. приходится искать определения этой приватной имплементации.
   
5. Бесплатная лицензия имеет некоторые ограничения. В частности, в ней не предусмотрена сборка статической версии программы, чтобы получить самодостаточный экзешник. Поэтому придётся тащить как миниум один или два рантаймных модулей библиотек - QtCore, QtGui. Цена вопроса - 12 мегов.

В целом, фреймворк достойный. Реальной альтернативы я ему не вижу. Конечно, для эффективной работы с ним придётся изрядно погнуть моск под его подходы: например, повсеместно используется new для создания объектов и очень редко можно увидеть delete - там широко применяется подход через удаление объектов в деструкторе предка, поэтому в каждом объекте виджета в конструкторе есть аргументом указатель на предка QObject *parent; или, скажем, строго заданная схема создания объектов-виджетов, при которой все объекты-виджеты создаются не в конструкторах, а уже во время запуска самой программы, т.е. после старта main().

Пристальное внимание надо уделить таким аспектам, как передача сообщений по схеме signal/slot, event'ам и event filter'ам. Это базовые вещи, без хорошего понимания которых, более-менее серьёзную программу не создать.

В общем, не всё там так просто и безпроблемно, но если готовы потратить силы и время на освоение, то дело это считаю достойным. Сам в процессе.