Это недоработка ваша или вашего начальства. В программирование крупных армов сам не лезу, но периодически просматриваю "чего там понаписали". Если обнаруживаю явный бред, то собираемся и корректируем идеологию.

Касательно языка и кросплатформенности - если есть время, то можете поэкспериментировать. В нашей конторе исторически использовались три языка: С,C++ и Delphi. К программистам нареканий не было, но стыковка разных модулей отнимала время и средства. В итоге было решено сделать три проекта на С++ и три на Delphi. Во всех случаях было требование переносимости, оценивалось общее время разработки нормализованное по сложности задачи. Также сознательно в ТЗ не были внесены некоторые пункты, с целью оценить время внесения изменений. Библиотеки и инструментарий программисты могли выбирать сами (в пределах разумного конечно).

Итог был (для меня) неожиданный - победил lazarus.freepascal.org. Один из программистов был сильно недоволен, но не привел убедительной аргументации, а обещание уволиться не выполнил.

С инструментарием с доступным исходным кодом нужно быть осторожным - особо инициативные пытались использовать свои патчи к fpc, но это было запрещено административно.

Когда-то для разработки софта для РС (для внутренних нужд) пользовался 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'ам. Это базовые вещи, без хорошего понимания которых, более-менее серьёзную программу не создать.

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

Ну, например, простой пример. Симуляторы разные. Где желательно полный перенос текста программы.

2 dxp. Огромное спасибо за развёрнутый ответ. Тем более что ваши знания в плюсах на голову больше моих.
Я ковыряюсь недели 2-3. Тем не менее по пунктам ...
1 - я уже понял в полном объёме. И вот тут у меня несколько вопросов. Надо ли вообще дизайнер? Или единожды делаешь размещение и лучше больше к нему не возвращаться? Он там хидер генерит автоматически и в случае изменений, соответственно его херит. Так есть вариант просто использовать другой хидер, взявши генерируемый за основу.
)) Не пинайте больно - я ещё сквозную идею не ухватил пакета. В дельфях форма менялась по ходу написания неоднократно. Часто так и писалось. Накидал компонентов - обработал, накидал ещё.
2. Тоже почти согласен. Особенно TAB убивает. Хотя остальное вполне понравилось. Особенно замена "." на "->" очень удобно. ))
Только мне слик не нравится. Вопрос: Зачем среду сборки менять???
И ещё один вопрос. В одном случае добился (!!) что абсолютно правильный проект вызывал ошибку при сборке. Причём ошибку VS почему-то. С предложением отослать )). Насколько сам пакет устойчиво работает???
3. SQL пока не нужен, но не исключаю естественно. Мне бы больше по работе с железом. Например с портами.
4. Насчёт отладки. Я решил, что просто не разобрался. Но пока мне показалось, что отладка ещё хуже чем в D7. Ну она уже и там далеко не на высоте. Насколько я заблуждаюсь?

Спасибо.

Вообще, имхо, нужен. Иногда надо разместить виджеты на форме и визуальный режим тут очень кстати. Но это, в общем-то, и всё. Не нужно от дизайнера хотеть кодогенерации, код лучше писать самому. С него достаточно того, что он позволяет настроить геометрию графических объектов - делать это в коде менее удобно, т.к. обычно приходится делать несколько итераций, чтобы добиться приемлемого вида.

Сам дизайнер держит всю информацию об объектах на форме в .ui файле. Он также генерит заголовок ui_xxx.h и может вставлять код (слоты в основном) при команде "Перейти к слоту...". Заголовок ui_xxx.h руками править не надо.


Ну, и тут так же. Только тут нет на форме невизуальных компонентов. Тут форма - это чисто для создания внешнего вида. Это у Борланда форма частично использовалась в качестве инструмента кодогенерации - можно было создавать объекты и подключать их к работе прямо мышкой. Потому оно и RAD система. А тут всё традиционно. По большому счёту это правильно, хотя после той расслабухи немного ломает.


Насчёт слика - это вы зря. Систему сборки я хочу менять потому, что меня тошнит от make и makefiles. Наелся этого. Давно юзаю SCons и очень этим доволен. Вот и хочу поднять сборку на его основе. Закончу этот проектик и попробую перетащить. В принципе, на SConc'е руление опциями проекта будет почти таким же, как и в их .pro файле.


У меня бывали падения a-la Segmentaion Fault, но во всех случаях сам был дурак. Как правило к этому приводят ошибки работы с памятью. Тут надо быть аккуратным. И иметь в виду, что ни один виджет не должен создаваться до инициализации приложения (создания объекта QApplication). Иначе работать не будет, а будут только неприятности в виде падений и глюков. Такая там идеология, надо быть в рамках.


С портами не привелось пока работать. Но думаю, что принципиальных проблем тут быть не должно. Допускаю, что какие-то вопросы возникнут, но это всё обычные рабочие моменты.


Отладчик там убогий. Он очень тормозной и весьма глючный. Мне сказали, что он портирован с линуха и там он работает не в пример лучше.

В принципе, сам-то дебаггер там - это GDB, а в оболочка предоставляет только фронт-энд к нему. Фронт-энды к GDB есть и другие, и получше. Слик, кстати, тоже умеет быть фронт-эндом к GDB. Люди, которые пробовали эту связку, отзывались очень похвально (знаю такого человека лично). Когда я переползу на свою среду (слик+сконс), тоже попробую.

Да уж. Отличный способ побороть текучку программистов - перейти с дельфей, которые знает практически каждый второй, на QT, который знаком очень немногим. Текучка от этого точно прекратится, все сбегут, и всё

Сначала надо перейти с дельфей на си-плюс-плюс, а потом уже на кути.

Им кажется, что знают, и даже собаку съели, хотя едва-ли каждый сотый из дельфийских "программистов" приступил к этой закуске. Это к сожалению порождает чрезмерно часто и удручающие качество продукта и ту самую "текучку" - наваяли что-то по быстрому и рванули лепить следующее

Сегодня только получил рассылку от Embarcadero. Оказывается у них уже есть продукт для создания облачных приложений - Embarcadero Delphi Prism XE
И на нем можно программировать даже айфоны.

После этого, конечно всякие QT идут в топку.
Хотя в течении обсуждения я не уловил причин почему при таких недостатках QT удостоился вообще какого-то внимания.

Каких недостатков?

Думаете, среди QT-программистов процент грамотных сильно выше? Сомневаюсь. Ну пусть даже немножко повыше, пусть не каждый сотый, а каждый 20й. В любом случае, в абсолютных числах грамотных дельфи-программистов значительно больше



Я поначалу испугался, когда узнал о продаже дельфей Embarcadero. Теперь вижу, что они молодцы, всё делают грамотно, может даже грамотнее чем Борланд.

Да. C++ + Qt имеет более высокий порог вхождения. Исходя из этого шутки про делфи-"программистов" вполне уместны.

Потому я и написал - каждый двадцатый вместо каждого сотого. Результирующего соотношения это не меняет.

Я извиняюсь, просто загромождать не хотел.
Не надо мешать всё в кучу.
От D7 просто пора уходить. Это я не хочу обсуждать. Причин я могу перечислить много. Уже довольно много пошло на ARM компов. Буки, к примеру. W8 решит проблему. А D7 кто перетранслирует? Уже указанные и не только мной, проблемы работы с разными языками. Выбор в России "национальной ОС". Хочешь не хочешь, но часть корпоративных компов перейдёт под Linux. У нас уже есть такие примеры. Газовики, в частности. А мы учётом газа, тепла и т.п. То есть кросплатформенность, в принципе понадобится. По крайней мере я так считаю. Пусть в одном случае из 50, от этого не легче.
Проблема текучки - не так проблематична. Проблематична низкая квалификация писателей, отсутствие общего подхода, отсутствие должного контроля. В этом смысле, C++ чуть более распологающий к порядку язык. Если бы всё решалось на уровне объектов, заимствовалось - документировалось, то было бы легче.
Понятно, что требуется человек, который определяет общую концепцию приложения, а только потом пишется это приложение. К сожалению, до сих пор писалось прямо на экране.
Приведу пример. Для выдачи команды в прибор, сейчас динамически создаётся отдельный поток и ставится в очередь потоков. Ну и поехало - в одном потоке - создаётся, в другом - уничтожается. Теперь где-то утечка памяти - найти программист не может. Координально менять - просто всё переписать надо. Приложение таково, что можно было бы создавать законченные объекты - тащить их из приложение в приложение и больше к этому не возвращаться.
===
Но и это я не хочу обсуждать. Я просто пытаюсь сорентироваться на перспективу. Для того, чтобы наметить работы на будущее.
Я рассматриваю и RAD. Но пока никто не описал преимуществ. А денег он стоит. А перспективы его - не менее туманны.
===
Облачные технологии нам не к чему пока. Насколько я понимаю. Как и VBA. Мы не офисные пакеты пишем, а пакеты привязанные к нашему железу.

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

Спасибо за ссылку на кроссплатформенную, бесплатную и, судя по Вашему рассказу, достойную замену Delphi