wl.>По-моему, Qt стремится к простоте, а Boost к библиотечной сложности

Qt стремится к божественным объектам, а тащит он за счёт готового функционала. По моей классификации программисты на Qt это четвёртое поколение программистов, которое я назвал пользователями.

Почему программисты прошлого были умнее (26.05.2022)

4. Поколение программистов пользователей (2000-2020+)

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

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

Начать с того, что есть разные подходы в программировании.
Для примера книга Функциональное программирование на языке C++. Чукич Иван.

Там на мой взгляд хорошо объясняется программирование без состояния и программирование с состоянием.
1. Просто Qt это по большей части объектно-ориентированное программирование за исключением контейнеров в стиле C++ где используется обобщённое программирование.
2. Boost же преимущественно использует обобщённое программирование, в частности обобщённое функциональное и обобщённое объектно-ориентированное.

Если не слишком вдаваться в детали, то это фактически объектно-ориентированное программирование в Qt против обобщённого в Boost. К примеру я особо не практиковал обобщённое программирование, хотя у него есть множество преимуществ в создании битомолок, а в основном использую объектно-ориентированное или даже процедурное. То есть я даже функциональное программирование не использую.

Так вот дело не в том, что там что-то сложнее, а в том, что раз я активно не практиковал обобщённое программирование, то лично для меня оно становится сложнее. Хотя это вовсе не значит, что оно сложнее. Я на ту же высшую математику забил уже 25 лет назад, потому меня и математик легко в математике обскачет.

А про то, что на Qt код нужно не писать, а попросту использовать и так понятно, но и производительности как в обобщённом программировании не жди. Я когда писал про if и switch намекал, что Qt как бы не пытается в производительность. И сигналы и слоты это довольно тормознутая штука сочетающая генерацию кода и очереди. Вот потому она и не попадёт в стандарт именно из Qt.

Вся же якобы лёгкость это объектно-ориентированная парадигма и уже кем-то написанный код. Самому писать код в объектно-ориентированной парадигме проще только если заморочиться именно им, но код не гибкий. Я об этом писал в статье.
Катастрофа ООП и многомерные модели данных (21.10.2021)

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

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

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

И здесь.
1. Если сигналы и слоты не входят прямо в стандарт C++, то честно сказать это мало интересно. Даже если их запихнут в STL не факт, что их будут использовать, как часто не используют и сам STL.
2. А если сигналы и слоты запихнут в стандарт C++, то понятно, что та же Qt вряд ли от этого будет полностью изменена под новый стандарт.

И даже C# это в основном приблуда для .NET, так же как Visual Basic.NET и прочие. Может быть и хорошо было бы добавить всю мета-объектную систему как в Qt или .NET в стандарт C++, то есть в сам язык, как об этом писал в книге Чистая архитектура. Мартин Роберт, говоря о поддержке парадигмы языком. Да, по сути мы сейчас говорим о добавлении ещё одной парадигмы в C++.

Парадигма программирования

Парадигмы программирования
    • Императивная
(контрастирует с декларативной) 
        ◦ Процедурная 
        ◦ Структурная 
        ◦ Аспектно-ориентированная 
        ◦ Объектно-ориентированная 
            ▪ Агентно-ориентированная 
            ▪ Компонентно-ориентированная 
            ▪ Прототипно-ориентированная
        ◦ Обобщённое программирование
    • Декларативная
(контрастирует с императивной) 
        ◦ Чистота языка 
            ▪ Чистота функции
        ◦ Функциональная 
            ▪ В терминах рефал-машины 
            ▪ Аппликативная 
            ▪ Комбинаторная 
            ▪ Бесточечная 
                • (чистая конкатенативная)
        ◦ Логическая 
            ▪ Ограничениями
    • Конкатенативная 
    • Векторная 
    • Метапрограммирование 
        ◦ Языково-ориентированная 
            ▪ Предметно-ориентированная 
            ▪ Пользователями
        ◦ Автоматизация процесса программирования
    • Рефлексивность 
        ◦ Гомоикони́чность
    • Связанные темы 
        ◦ Программирование в крупном и мелком масштабе[англ.] 
        ◦ Модульность 
        ◦ Полиморфизм 
        ◦ Продолжения и CPS 
        ◦ Параллелизм
    • Методы и алгоритмы 
        ◦ Автоматное 
        ◦ Потоков данных 
        ◦ Событийно-ориентированное 
        ◦ Реактивное 
        ◦ Сервис-ориентированное

Но это просто разговоры. А почему тогда там всего остального нет. И чтобы было оптимизировано компилятором на машинном уровне, а не вот так грубо что-то генерировать из готовых инструкций языка C++.

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

wl.>насколько я понимаю, в том же C# подобная функциональность это часть стандарта языка, причем очень активно использующаяся
Да это частное решение частной конторы.
Пока не до таких мелочей — рефлексию внедряют.

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

wl.>>насколько я понимаю, в том же C# подобная функциональность это часть стандарта языка, причем очень активно использующаяся
LVV>Да это частное решение частной конторы.
LVV>Пока не до таких мелочей — рефлексию внедряют.

в том посте, что Мессия привел, тоже про рефлексию пишут, типа без неё никак. ну чтож

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

wl.>Здравствуйте, LaptevVV, Вы писали:

wl.>>>насколько я понимаю, в том же C# подобная функциональность это часть стандарта языка, причем очень активно использующаяся
LVV>>Да это частное решение частной конторы.
LVV>>Пока не до таких мелочей — рефлексию внедряют.

wl.>в том посте, что Мессия привел, тоже про рефлексию пишут, типа без неё никак. ну чтож

рефлексия поможет только отказаться от внешний утилит которые moc обрабатывают
но тянуть в язык эти сигналы, так себе удовольствие

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

wl.>>в том посте, что Мессия привел, тоже про рефлексию пишут, типа без неё никак. ну чтож
ВМ>рефлексия поможет только отказаться от внешний утилит которые moc обрабатывают
ВМ>но тянуть в язык эти сигналы, так себе удовольствие

ну yield же притащили, и потоки! остался последний шажок

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

wl.>Здравствуйте, Великий Мессия, Вы писали:

wl.>>>в том посте, что Мессия привел, тоже про рефлексию пишут, типа без неё никак. ну чтож
ВМ>>рефлексия поможет только отказаться от внешний утилит которые moc обрабатывают
ВМ>>но тянуть в язык эти сигналы, так себе удовольствие

wl.>ну yield же притащили, и потоки! остался последний шажок

yield != co_yield

но повторюсь
сигналы за пределами куте не нужны
а завезенные экзекуторы в С++26
умеют строить connect() итд цепочки

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

все остальное в С++ решается без сигналов и слотов
даже asio без них чудесно поживает

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

wl.>насколько я понимаю, в том же C# подобная функциональность это часть стандарта языка, причем очень активно использующаяся

Потому что для этого нужна кутешная модель работы с памятью (родитель — дочерние). Там совсем все по-другому, не как в обычных плюсах. Такая своя отдельная волость со своим стилем написания программного кода

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

Ф>>Да, это делфля. У них в язык диспатчер виндовых сообщений втроен, прямо в Object'е есть метод Dispatch(). Подробнее тут.

M>Нет, диспатчер не встроен в язык, это исключительно библиотечная пристройка. А вот это как называется? Вот ты знаешь способ, которым можно отлючить эту "библиотечную" приблуду? Я про то, что это system.pas и это вообще метод корневого класса — предка вообще всех классов в делфе. Exit, тащемта тамже находится.

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

D>Здравствуйте, wl., Вы писали:

wl.>>насколько я понимаю, в том же C# подобная функциональность это часть стандарта языка, причем очень активно использующаяся

D>Потому что для этого нужна кутешная модель работы с памятью (родитель — дочерние). Там совсем все по-другому, не как в обычных плюсах. Такая своя отдельная волость со своим стилем написания программного кода

да, точно, в C# тоже есть базовый класс со всей функциональностью

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

Ф>>>Да, это делфля. У них в язык диспатчер виндовых сообщений втроен, прямо в Object'е есть метод Dispatch(). Подробнее тут.

M>>Нет, диспатчер не встроен в язык, это исключительно библиотечная пристройка.


Поправил ответ, ты же это писал:

Ф>А вот это как называется? Вот ты знаешь способ, которым можно отлючить эту "библиотечную" приблуду? Я про то, что это system.pas и это вообще метод корневого класса — предка вообще всех классов в делфе. Exit, тащемта тамже находится.

Это — библиотека. То, что в библиотеке есть God-object, ничего не меняет. Это как сказать, что Qt — это часть языка C++, потому там тоже есть свой God-object — QObject.

Я хз, как на дельфи, но на билдере можно было вполне писать консольные проги (да и виндовые, так-то, тоже, но без VCL этим, думаю, мало кто занимался). Думаю, на Дельфи тоже можно было писать консольные проги без VCL, c виндовыми, конечно, там наверняка гораздо сложнее, чем в плюсах

ВМ>что бы понимать что основная нагрузка идет
ВМ>на разбор и отфутболивание тупых пропозлов
Да, а пропускают самые мозгодробильные. В этом и беда С++.

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

wl.>насколько я понимаю, в том же C# подобная функциональность это часть стандарта языка, причем очень активно использующаяся

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

P.S. по поводу moc компилятора — он не нужен для сигналов/слотов. Уже давно есть проект, который практически полностью его заменяет — https://github.com/woboq/verdigris

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

Ф> Вот ты знаешь способ, которым можно отлючить эту "библиотечную" приблуду?

Редактируешь system.pas, пересобираешь RTL... Только зачем Это же просто диспетчеризация вызова метода. Тот же самый механизм используется для вызова динамических (не виртуальных) методов. Тот факт, что обработка оконных сообщений так красиво легла на древний механизм диспетчеризации не означает, что диспатчинг был сделан специально под нее (динамические методы еще в Turbo Pascal были). Кстати, во Free Pascal пошли дальше, там сообщения могут иметь строковый идентификатор.

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

LVV> Пока не до таких мелочей — рефлексию внедряют.

Почитал статью на хабре про эту вашу рефлексию в сисплюсах. Парсинг джисона в компайлтайм это, конечно, круто, но...

А главное, зачем??

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

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

LVV>> Пока не до таких мелочей — рефлексию внедряют.

R>Почитал статью на хабре про эту вашу рефлексию в сисплюсах. Парсинг джисона в компайлтайм это, конечно, круто, но...
R>А главное, зачем??

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

т.е. эти протобуфы, moc для QT итд все уберется

к примеру есть у тебя структура
что бы ее сериализвать
надо в ручную писать сериализатор к каждому полю
или выкручиваться через всякие хитрые SFINAE как это делал полухин и протянул в буст
теперь это не надо
средствами язык
можно добраться до всего что написано на С++
имя переменной к примеру в функции или в классе
ну итд

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

R>Почитал статью на хабре про эту вашу рефлексию в сисплюсах. Парсинг джисона в компайлтайм это, конечно, круто, но...
R>А главное, зачем??

Рефлексия в практическом плане нужна для того, чтобы создавать скрипты или иные управляющие структуры вроде машин состояний на основе уже скомпилированных библиотек. Сейчас к этому делу подвязали тот же Python, то есть вызывают библиотеке Си и C++ из него, но для этого нужна обёртка (wrapper) для него.

А если возвратиться в прошлое, то есть консорциум Object Management Group и продвигаемые технологии не только UML, но и какие-нибудь CORBA и DDS. Только в одном случае главное это удалённый вызов функций, а в другом управление через состояние данных.

У Майкрософт ещё была технология DCOM, кстати, довольно плохая вещь, когда на неё стали делать ставку производители оборудования для автоматизации. Я про ту дрянь под названием OPC сервера.

В общем лично я выделяю два направления как и написал выше.
1. Вызов.
2. Данные.

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

Но с точки зрения нормального сиплюсплюсника, который имеет код и компилирует его когда надо, конечно, всё это ерунда. Причём я сам не раз это писал в отношении тех же плагинов. Если производитель софта не может сам делать софт включая плагины, но последнее только чисто для удобства разработки и обновлений, а ему нужны сторонние разработчики, то это как бы такое себе.

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

R>Почитал статью на хабре про эту вашу рефлексию в сисплюсах. Парсинг джисона в компайлтайм это, конечно, круто, но...
R>Image: 5acb9b38b1c7e32f706f27c6.jpg
R>А главное, зачем??

Я лично понял это как proof of concept. Короче, буквально не воспринимаю.
А статическая рефлексия сама по себе — это нужная штука.

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

LVV>> Пока не до таких мелочей — рефлексию внедряют.

R>Почитал статью на хабре про эту вашу рефлексию в сисплюсах. Парсинг джисона в компайлтайм это, конечно, круто, но...
R>Image: 5acb9b38b1c7e32f706f27c6.jpg
R>А главное, зачем??
Уже написали, просто добавлю. Чтобы избавится от внешних инструментов(шагов)
Qt(moc), protobuf(protoc), odb, ну и появятся новые всякие ORM

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

R>>А главное, зачем??
I>Уже написали, просто добавлю. Чтобы избавится от внешних инструментов(шагов)
А зачем от них избавляться?

I>Qt(moc), protobuf(protoc), odb, ну и появятся новые всякие ORM
Эти самые protobuf генераторы делают для всех языков, даже таких как c#/java/etc в которых и с рефлексией всё в порядке, и даже встроенная кодогенерация есть. И даже для js есть генераторы.

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

R>>Почитал статью на хабре про эту вашу рефлексию в сисплюсах. Парсинг джисона в компайлтайм это, конечно, круто, но...
R>>А главное, зачем??
V>Рефлексия в практическом плане нужна для того, чтобы создавать скрипты или иные управляющие структуры вроде машин состояний на основе уже скомпилированных библиотек.
А как дела обстоят в С++ с компилированными библиотеками? Хоть бинарную совместимость-то осилили? И замутить рефлексию даже возможно??!