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

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

SaZ>>Qt vs HTML.
S>А тебе исходники того, что они там демонстрируют, не попадались? На картинке красиво, но хотелось бы потрогать...

Увы нет, и уже нет контактов в Qt, чтобы спросить . Я думаю, что можно попробовать написать напрямую на почту разрабам этого примера.

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

MTD>Не проблема, бери написанный на Sciter — все летать будет. Или тоже тормозить? Не знаю, расскажешь.

Спасибо но вариант не совсем подходит, есть еще?

Зачем сразу в "бутылку" лезть?

Ни первый ни второй я не использую. Я совершенно в другой области работаю.

Во вторых, наверяка кроме выбора библиотеки там еще некий чудак на букву М решил добавить дизайна. И эти все текстуры и прочие ненужные "красоты" хотелось бы выпилить.

Что касается меня, то я, конечно, ICQ бы не использовал. Чтобы хоть как-то не оттолкнуть старых клиентов, я бы оставил простой клиент (см. V 6). Кому нужны эти красоты? Старым гламурным кисам? Новые точно не будут использовать ICQ.

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

Если подскажешь как хоть как-то ускорить это дело, буду признателен. Чтобы простой плоский дизайн. Может настройкак какая "FumigateGayDesign=1" ?

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

_>>О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? )
SaZ>А чем мешает препроцессор?
SaZ>https://woboq.com/blog/moc-myths.html

Потому что для реализации в C++ системы типа signal/slot никакие препроцессоры не нужны — см. множество соответствующих библиотек. Про бритву Оккама помним? )

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

V_>Чтобы хоть как-то не оттолкнуть старых клиентов, я бы оставил простой клиент (см. V 6).

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

V_>Если подскажешь как хоть как-то ускорить это дело, буду признателен. Чтобы простой плоский дизайн. Может настройкак какая "FumigateGayDesign=1" ?

Увы, такой нет.

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


MTD>Ты не поверишь, я сам за это топил, но развитие продукта определяют не программисты.

Спасибо, я так и думал. Примерно всегда так и происходит. Одна из причин почему предпочитаю стартапы, без метастазов политики и маразма.

донесешь feedback от "реальных клиентов" ?

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

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

MTD>Увы, такой нет.

А вы в QApplication передаёте реальные параметры командной строки? Может туда какой Fusion + кастомный QSS можно подсунуть? Хотя из того что я помню по коду (смотрел давно и поверхностно), там не так уж и в лоб делается кастомизация.

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

_>Потому что для реализации в C++ системы типа signal/slot никакие препроцессоры не нужны — см. множество соответствующих библиотек. Про бритву Оккама помним? )

Ну вот вы явно не прочитали, про что там написано. Для сигналов/слотов — уже не нужно. А вот для рефлексии/удобных вариантов/интроспекции, с поддержкой С++03 (А в Qt4 и С++98), кодогенерация — очень удобное решение, чтобы не городить всякие макрошаблонные извращения.

З.Ы. помню как-то хотел ради сигналов/слотов, интроспекции и локализации прикрутить к проекту Qt. Но начальство упёрлось рогом, мол никаких 3rdparty. В результате — самописный event loop, самописная локализация, китайский CPGF (изврат ещё тот).

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

SaZ>Увы нет, и уже нет контактов в Qt, чтобы спросить . Я думаю, что можно попробовать написать напрямую на почту разрабам этого примера.
Вообще странно, что они это не выложили в исходниках, всю идею убили.

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

S>Вообще странно, что они это не выложили в исходниках, всю идею убили.

Они, как я понял, будут делать technology preview, чтобы показать, что QML можно свободно встроить в браузеры и использовать вместо классического html dom. При том, что с QML намного удобнее работать при практически тех же возможностях. Плюс — QML из коробки умеет javascript. Уже, кстати, были демки, где QtQuick приложения запускали через emscripten или через WebGL steam.

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

_>>Потому что для реализации в C++ системы типа signal/slot никакие препроцессоры не нужны — см. множество соответствующих библиотек. Про бритву Оккама помним? )
SaZ>Ну вот вы явно не прочитали, про что там написано. Для сигналов/слотов — уже не нужно. А вот для рефлексии/удобных вариантов/интроспекции, с поддержкой С++03 (А в Qt4 и С++98), кодогенерация — очень удобное решение, чтобы не городить всякие макрошаблонные извращения.

Ну вот я использую C++17, сигналы/слоты и не использую рефлексию. Можно мне получить версию Qt, которая будет нормально работать (включая все инструменты) без препроцессора? Ещё древняя MFC на древнем C++ это умела...

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

_>Ну вот я использую C++17, сигналы/слоты и не использую рефлексию. Можно мне получить версию Qt, которая будет нормально работать (включая все инструменты) без препроцессора? Ещё древняя MFC на древнем C++ это умела...

В древней MFC был зоопарк макросов (не говоря уже о всех костылях и сложностях в разработке кастомных контролов, которые приходилось использовать).

Ешё раз: если вам не нужна рефлексия, то зачем вам Qt?
И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.

Qt — популярный инструмент, который предоставляет определённый backward compatibility. Когда будет Qt6, С++20 будет поддерживаться основными компиляторами, тогда можно будет и без препроцессора.
И да, есть Verdigris который более-менее позволяет Qt без препроцессора.

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

_>>Ну вот я использую C++17, сигналы/слоты и не использую рефлексию. Можно мне получить версию Qt, которая будет нормально работать (включая все инструменты) без препроцессора? Ещё древняя MFC на древнем C++ это умела...
SaZ>В древней MFC был зоопарк макросов (не говоря уже о всех костылях и сложностях в разработке кастомных контролов, которые приходилось использовать).

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

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

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

SaZ>Ешё раз: если вам не нужна рефлексия, то зачем вам Qt?

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

SaZ>И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.

Вполне однозначный ответ уже был озвучен здесь http://rsdn.org/forum/cpp.applied/6907324.1

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

.

SaZ>Qt — популярный инструмент, который предоставляет определённый backward compatibility. Когда будет Qt6, С++20 будет поддерживаться основными компиляторами, тогда можно будет и без препроцессора.

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

SaZ>И да, есть Verdigris который более-менее позволяет Qt без препроцессора.

Любопытно. Интересно, IDE нормально это понимает (чтобы не сломался описанный выше механизм работы) или нет? )

Здравствуйте, 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 (пока там очень сырая альфа) — то будет круто.

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

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

Для меня особенно показателен пример правильный с точки зрения фундаменталистов (все средствами языка), но совершенно абсурдный с точки зрения разума — Boost Spirit. Можно взять yacc или что-то подобное, встроить в сборку, компилировать за доли секунды, иметь нормальную диагностику ошибок и гибкость для модификации. А можно взять спирит, компилировать по 5-10 минут, получать сообщения об ошибки в 400 строк из которых ничего не понятно и боятся лишний раз тронуть написанное. Еще лично для меня забавно выглядят все наезды на препроцессор от пользователей языка, где препроцессинг вообще стадия компиляции.

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

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

Ну во-первых данная "очень качественная архитектура" (даже смешно читать подобные эпитеты в отношение Qt в 2017-ом году) является просто стандартной реализацией одного из самых старых и известных паттернов проектирования. Который существовал задолго до рождения Qt и который применяется в большинстве кроссплатформенных библиотек.

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

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

Повторяю уже не первый раз: никаких извращений для поддержки реализации сигналов в C++ не требуется. Это должно бы очевидно каждому, даже после знакомства с языком на уровне статьи из Википедии. Просто потому что в C++ (да и даже в C) указатель на функцию является первоклассной сущностью. Более того, полно готовых (и совсем не новых) библиотек на эту тему (например http://www.boost.org/doc/libs/1_65_1/doc/html/signals2.html), оборачивающих эту базовую возможность языка в удобные ООП конструкции.

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

Кому проще то? Уж явно не пользователям их библиотеки...

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

Жирная не в смысле размера дистрибутива (хотя тут конечно тоже не всё хорошо, но по сравнению со всякими новомодными Электронами и т.п. можно считать что нормально), а в смысле устройства библиотеки.

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

Угу, всё приложение в одном убогом Java-стиле. ))) Нет, спасибо, не надо такого "удовольствия". ))) Ну и кстати все эти не GUI модули (базы, сеть, потоки и т.п.) являются крайне жалкими по сравнению с нормальными современными C++ инструментами в соответствующих областях. Точнее и GUI часть в Qt точно такая же кривая, но у неё просто нет настолько же полнофункциональных аналогов. А вот во всех других областях такие аналоги есть и они на голову выше реализации в Qt.

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

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

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

Я вроде как ясно сказал, что мне от Qt только и нужна эта "малая часть" (GUI).

SaZ>В принципе можно, но нужны будут другие подходы, которые с С++14 усложнят программирование относительно того, что можно делать с кодогенерацией.

Не аргументированные сказки.

_>>Это если нужна рефлексия (которая для GUI вообще ни к чему). А если без неё, то можно было без препроцессора уже 20 лет назад.
SaZ>Расскажите про GUI, который вы делаете?
SaZ>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.

unordered_map<string, unique_ptr<property_base>> dynamic_properties;

Ага, тонны кода. Ну да, ну да.

SaZ>>>И да, есть Verdigris который более-менее позволяет Qt без препроцессора.
_>>Любопытно. Интересно, IDE нормально это понимает (чтобы не сломался описанный выше механизм работы) или нет? )
SaZ>ReSharper — точно нормально, так же как и сгенерированный Qt код. Но всё это баловство, которое усложняет разработку. Вот если они доведут до ума свой проект по переделке moc на основе clang (пока там очень сырая альфа) — то будет круто.

Речь не про парсинг исходников (который кстати в современном QtCreator с включённой ClangModel стал лучше любых Решарперов), а про работу с дизйанером GUI, который работает с обработчиками для контролов как со слотами.

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


MTD>Для меня особенно показателен пример правильный с точки зрения фундаменталистов (все средствами языка), но совершенно абсурдный с точки зрения разума — Boost Spirit. Можно взять yacc или что-то подобное, встроить в сборку, компилировать за доли секунды, иметь нормальную диагностику ошибок и гибкость для модификации. А можно взять спирит, компилировать по 5-10 минут, получать сообщения об ошибки в 400 строк из которых ничего не понятно и боятся лишний раз тронуть написанное. Еще лично для меня забавно выглядят все наезды на препроцессор от пользователей языка, где препроцессинг вообще стадия компиляции.

Оу, какие у нас тут специалисты подъехали... )))

Ну т.е. тебя тогда не затруднит показать пример красивой реализации на yacc скажем простейшего кода загрузки в vector массива double чисел, хранящихся в большом текстовом файле (скажем в американском формате с точкой и разделённых между собой запятой)? На spirit'е это будет одна коротенькая строчка. Ну а когда справишься с собственно написанием кода, то попробуем ещё померить получившуюся производительность...

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

_>Оу, какие у нас тут специалисты подъехали... )))

По-существу обсуждать тебе видимо нечего, решил сразу на личность съехать?

_>Ну т.е. тебя тогда не затруднит показать пример красивой реализации на yacc скажем простейшего кода загрузки в vector массива double чисел, хранящихся в большом текстовом файле (скажем в американском формате с точкой и разделённых между собой запятой)?

А зачем для этого нужен yacc или Spirit? Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.

_>Ну а когда справишься с собственно написанием кода, то попробуем ещё померить получившуюся производительность...

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

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

_>>Оу, какие у нас тут специалисты подъехали... )))
MTD>По-существу обсуждать тебе видимо нечего, решил сразу на личность съехать?

Это не переход на личности (если что, у меня к тебе никакого негатива нет), а именно по делу. Потому как Boost.Spirit — это как раз один из весьма ярких и известных примеров современного направления развития C++. Который демонстрирует возможности, абсолютно недоступные ни в одном другом мейнстрим языке. Так что когда вроде как C++'ик пишет подобное про Spirit (я уже молчу про сравнение с yacc), то это вызывает вопросы...

_>>Ну т.е. тебя тогда не затруднит показать пример красивой реализации на yacc скажем простейшего кода загрузки в vector массива double чисел, хранящихся в большом текстовом файле (скажем в американском формате с точкой и разделённых между собой запятой)?
MTD>А зачем для этого нужен yacc или Spirit?

Ну предложи своё решение данной задачки) Чтобы с такой же краткостью и быстродействием.

MTD>Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.

Про удобство поддержки очевидно как раз всё наоборот — одна краткая строчка против целого нетривиального файла.

Что же касается времени компиляции и ошибок, то тут определённые недостатки есть, но они вполне себе исправляются. Время компиляции у меня например не минуты, а секунды (потому что любой профессионал в C++ работает только с помощью эффективных SSD). А для эффективной обработки ошибок в шаблонах в C++ как раз и вводят концепты. Да, в C++17 они не успели попасть (хотя в gcc уже давно работают), но в C++20 будут уже 100% и тогда все подобные библиотеки получат эффективный инструмент для нормальных сообщений об ошибках (сейчас в принципе тоже можно через enable_if, но уж слишком громоздкой — мало кто реализует полноценно).

_>>Ну а когда справишься с собственно написанием кода, то попробуем ещё померить получившуюся производительность...
MTD>Зачем? Я уверен у yacc производительность достаточно хорошая, а в экстремальных случаях можно навелосипедить с учетом знания входных данных и уделать любой универсальный генератор парсеров.

Просто чтобы было понятно, что преимущество одновременно по всем параметрам (и лаконичность кода и удобство интеграции и итоговое быстродействие).

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

_>Потому как Boost.Spirit — это как раз один из весьма ярких и известных примеров современного направления развития C++.

Это не то развитие которого ждет индустрия. С точки зрения ученого да, все классно, средствами языка можно все выразить, невероятная мощь, ребята умные, спору нет, вот только когда нужно просто дом построить им становится неинтересно, слишком приземленно. Нужен инженер, а у инженера интеллектуальные способности несколько иные и потребности отличаются. Инженеру же нужен простой, удобный и быстрый инструмент. Я пробовал использовать Boost.Spirit и в процессе мне постоянно приходилось думать как делать, а не о том, что мне нужно сделать, в то время как yacc прост как палка и понятен. С++ стал популярен, потому что на тот момент времен затачивался под инженеров, а буст в массе пилят ученые, поэтому многие библиотеки из него использует дай бог сотня людей во всем мире. Здесь показателен другой язык заточенный под решение практических задач, а потому неплохо выстрелившим, я о Go — недавно Мейл.ру проводил хайлоад кап, так первые строчки все были заняты Go уже через несколько дней, в то время как решения на плюсах появились только где-то к концу второй недели, при этом по быстродействию не сказать, что Go был порван. Вот тебе и соотношение скорость разработки на скорость выполнения.

_>Ну предложи своё решение данной задачки) Чтобы с такой же краткостью и быстродействием.

Установить локаль, читать из потока.

MTD>>Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.

_>Про удобство поддержки очевидно как раз всё наоборот — одна краткая строчка против целого нетривиального файла.

Что там нетривиального-то? Все просто как палка. А еще для отладки грамматик есть инструменты.

_>Время компиляции у меня например не минуты, а секунды (потому что любой профессионал в C++ работает только с помощью эффективных SSD).

Да SSD сейчас у всех, нашел чем удивить, вот только не панацея это. Реакция людей пересевших, например с С# на плюсы — компиляция подвисла, что делать.

_>Просто чтобы было понятно, что преимущество одновременно по всем параметрам (и лаконичность кода и удобство интеграции и итоговое быстродействие).

Я пока у Spirit не вижу вообще никаких преимуществ кроме идеологических.

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

_>Ну во-первых данная "очень качественная архитектура" (даже смешно читать подобные эпитеты в отношение Qt в 2017-ом году) является просто стандартной реализацией одного из самых старых и известных паттернов проектирования. Который существовал задолго до рождения Qt и который применяется в большинстве кроссплатформенных библиотек.

Я не говорю, что они изобрели новые паттерны. Просто они их удачно применили.

_>А во-вторых этот вопрос вообще не имеет никакого отношения к нашей дискуссии, т.к. обсуждаемый нами препроцессор вообще никак не связан с упомянутыми особенностями архитектуры, а занят исключительно поддержкой кривой реализации системы сигналов и метаинформацией.

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

_>Повторяю уже не первый раз: никаких извращений для поддержки реализации сигналов в C++ не требуется. Это должно бы очевидно каждому, даже после знакомства с языком на уровне статьи из Википедии. Просто потому что в C++ (да и даже в C) указатель на функцию является первоклассной сущностью. Более того, полно готовых (и совсем не новых) библиотек на эту тему (например http://www.boost.org/doc/libs/1_65_1/doc/html/signals2.html), оборачивающих эту базовую возможность языка в удобные ООП конструкции.

Ну лично мне намного удобнее объявить
void clicked(); вместо boost::signals2::signal<void ()> clicked;
и
connect( источник, метод, приёмник, метод, [тип соединения] ); вместо (из примеров буста) deliverNews.connect(signal_type::slot_type(&NewsMessageArea::displayNews,
newsMessageArea.get(), _1).track(newsMessageArea));

И да, про поддержку компиляторов — выше. Реальных недостатков препроцессора вы пока не написали. Только идеологические.

_>Кому проще то? Уж явно не пользователям их библиотеки...

У меня, как у активного пользователя Qt, не было проблем с подключением moc-а к сборке. Тот же CMake из коробки умеет.

_>Жирная не в смысле размера дистрибутива (хотя тут конечно тоже не всё хорошо, но по сравнению со всякими новомодными Электронами и т.п. можно считать что нормально), а в смысле устройства библиотеки.

Так чем плохое устройство? Понять принцип сигналов/слотов, который синтаксически проще, чем буст или аналоги. Понять что такое QObject, когда он нужен и модель управления временем жизни объекта (parent/child). Понять, что такое event loop (тоже не вижу проблем, если знаком с разработкой GUI). А остальное — уже по вкусу.

_>Угу, всё приложение в одном убогом Java-стиле. ))) Нет, спасибо, не надо такого "удовольствия". )))

А что такое Java стиль? Не понимаю о чём вы.

_>Ну и кстати все эти не GUI модули (базы, сеть, потоки и т.п.) являются крайне жалкими по сравнению с нормальными современными C++ инструментами в соответствующих областях. Точнее и GUI часть в Qt точно такая же кривая, но у неё просто нет настолько же полнофункциональных аналогов. А вот во всех других областях такие аналоги есть и они на голову выше реализации в Qt.

Ну так с базами на C++ в принципе плохо, особенно с универсальными провайдерами. Я кроме QxOrm и SQLAPI ничего внятного не видел. ODB с натяжкой, слишком интрузивный.

_>Я вроде как ясно сказал, что мне от Qt только и нужна эта "малая часть" (GUI).

Терпите. Весь мир утонул в необходимости backward compatibility

_>Не аргументированные сказки.

Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.

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

_>unordered_map<string, unique_ptr<property_base>> dynamic_properties;
_>

_>Ага, тонны кода. Ну да, ну да.

Ни о чём код. Мы видимо о разном говорим. Про Spirit и его лаконичность тут где-то рядом уже всё написали.
Вопрос был, кто и при помощи каких данных заполнит эту мапу? Без рефлексии — придётся на каждый написанный класс писать ещё метод для заполнения этой мапы. При редактировании класса — чинить этот метод и т.д.