Здравствуйте, alex_public, Вы писали:

_>Однако можно было без проблем кинуть кнопку на форму, нажать по ней правую кнопку мыши, выбрать пункт меню типа (сейчас уже естественно не помню) "Перейти к обработчику" и ты оказывался в коде обработчика (причём если его раньше не существовало, то он генерировался средой на ходу). И всё это работало без всяких внешних препроцессоров 20 лет назад.

Работало, но не кросс-платформенно. Для кросс-платформенной библиотеки надо делать очень толстый слой абстракции, который не всегда можно тривиально реализовать. У Qt же сейчас очень качественная архитектура, которая позволяет достаточно легко добавить поддержку новых платформ (и этой возможностью пользуются, как-то собеседовался на фирму, которая как раз свой порт Qt под какое-то железо делала).
Похоже, тут всё-таки вопрос вкуса. Гуглу для работы протобафа нужен кодогенератор, gsoap — аналогично, WinForms — тоже кодогенерация, пусть и средствами компилятора (хоть и .net). Уверен, что можно ещё много примеров найти.
Лично я тут проблемы не вижу. Для меня кодогенерация — намного более правильное решение, чем извращение со средствами языка.

_>В wxWidgets аналогично, но гораздо более продвинуто (с произвольными сообщениями и т.п.). И опять же без всяких внешних препроцессоров и кстати даже без макросов.

Ну удачи им с портированием на Android. Опять же — список поддерживаемых платформ у Qt на порядок длиннее. Тот же QNX.

_>Соответственно в Qt по сути всё тоже самое, только вот зачем-то понадобился внешний препроцессор.

Затем, что так проще.

_>Мне не нужна Qt. Мне нужна GUI библиотека, позволяющая делать качественные, нативно выглядящие интерфейсы для Android/Windows/iOS/OSX/Linux (естественно с одной кодовой базой). Если кто-то подскажет мне другой инструмент с такой функциональностью, то я с радостью выброшу этого жирного монстра (Qt) подальше — всё равно весь не GUI код у меня использует только нормальные библиотеки (стандартная библиотека языка, Boost и т.п.). Однако к большому сожалению ни одного сравнимого инструмента не видно, так что приходится пользоваться этим.

Да, и сделать такой инструмент с нуля ну очень тяжело. Майкрософт вон пытаются ксамарин впихнуть. Но опять же — это .net.
Не понимаю только, почему вы Qt называете жирным? QtLite + статическая линковка + UPX и размер приложения уже получается очень маленький. Опять же — это только если есть смысл заморачиваться по размеру. Мне только в одном проекте пришлось.

Ещё одно достоинство Qt, которое косвенно влияет на размер дистрибутива — с Qt не нужно тащить зоопарк 3rdparty и писать между ними адаптеры. Базы, сеть, потоки, веб, 2д3д графика, парсеры — всё использует общие типы данных и можно писать код в одном стиле.

SaZ>>И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.
_>Вполне однозначный ответ уже был озвучен здесь http://rsdn.org/forum/cpp.applied/6907324.1

Автор: alex_public
Дата: 18.09.17

.

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

_>Это если нужна рефлексия (которая для GUI вообще ни к чему). А если без неё, то можно было без препроцессора уже 20 лет назад.

Расскажите про GUI, который вы делаете?
Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.

SaZ>>И да, есть Verdigris который более-менее позволяет Qt без препроцессора.
_>Любопытно. Интересно, IDE нормально это понимает (чтобы не сломался описанный выше механизм работы) или нет? )

ReSharper — точно нормально, так же как и сгенерированный Qt код. Но всё это баловство, которое усложняет разработку. Вот если они доведут до ума свой проект по переделке moc на основе clang (пока там очень сырая альфа) — то будет круто.