Ну я бы не был столь категоричен. В edba 143 коммита, последний был 2.5 года назад, cppdb дальше cppcms не забралась и, видимо, поэтому была заброшена.
У soci 2450 коммитов, последний был пару месяцев назад, сам проект уже черти когда назад начал писаться. На самом деле, продукт зрелый.
Еще в Qt4 это сделали. И надо сказать, что Qt4 появился аж в 2005 году, 13 лет назад. А это времена, когда никаких умных указателей и потоков в GCC не было, не говоря уж про msvc.
Qt3 — это 2001 год. К слову, первый интелловский двухядерный процессор Pentium D и амдешный Opteron появились только в 2005. И я не уверен, что там была отличная аппаратная поддержка атомарных операций (во всяком случае, компиляторы точно не умели правильно генерировать код). В тоже время, Qt3 имеет поддержку потоков (треды, мьютексы, conditional variable и прочее). И мне кажется, вы слишком много просите для того времени.
Но, как по мне, лучше бы перешли на стандартную строку.
Конечно, нет. Строки в стандарте — это ужас. Вернее, как мы уже обсудили выше, строк как таковых в стандарте нет вообще.
На сколько я знаю, QString не умеет нормально работать с комбинированными символами, состоящими из двух двухбайтовых слов
Опять же, Qt давно имеет эти классы, на них уже написано много кода, они хорошо, логично и удобно реализованы. Зачем ломать удобные классы, только лишь потому, что в стандарте недавно появилось аналогичное?
Я за то, чтобы заменить заведомо костыльные вещи на что-то новое и удобное. moc — замечательный костыль своего времени, но сейчас его можно реализовать элегантнее, не сломав старый код. Слоты в Qt5, благодаря лямбдам, стали намного удобнее и красивее. Вот я за такие изменения.
Кстати, на Qt чаще ругаются не когда они вводят что-то новое (за это наоборот все радуются), а когда они что-то удаляют. Как было, например, с перехода QtWebKit на QtWebEngine. Вот тут у людей были болезненные переходы.
И еще есть момент. Qt очень часто голым используется в embedded устройствах, прям минуя STL. Если памяти довольно мало, то практически всегда выгоднее тащить с собой QtCore с огромным функционалом из коробки, вместо довольно голого STL.
Еще раз: возвращается количество объектов QChar. В кодировке UTF-16 при значения больше 65535 используется 2 объекта QChar (ну потому что стандарт так говорит). Вполне логично, что на запрос размера мне возвращается количество QChar.
std::wstring
Ага, только wchar_t в винде занимает 2 байта, а в никсах — 4 байта. Со всеми вытекающими проблемами отсюда.
Практически в qt5 реализация QString вынуждена использовать блокировки
Все-таки внутри QString (да и вообще всех классов Qt, использующих implicit sharing) используются атомарные счетчики, а не стандартные блокирующие примитивы. Как только мы копируем объект, счетчик ссылок увеличивается на один, и мы получаем легкую копию (shallow copy). Если мы хотим изменить объект, вызывается detach и мы получаем глубокую копию (deep copy).
Так вот, если мы делаем копию строку в другом потоке, сначала получаем shallow копию, увеличиваем счетчик и работаем с shared данными. Как только мы начинаем изменять объект, мы получаем отвязанную локальную копию нашей строки, которая уже не ссылается на данные в других потоках. Ее изменение происходит локально, ничего нигде не сломается.
Совсем другое дело, если наша строка являются общей для разных поток, и они ее пытаются изменить. Да, тут нужны традиционные блокировки аля mutex, но это ровно также нужно и со всеми другими типами данных (то есть, аналогично нам нужно было бы сделать и с std::string). QString является реентерабельной функцией, не потокобезопасной.
Вообще, для решения такой проблемы (совместное изменение общих данных) разработчики рекомендуют использовать сигналы-слоты.
С чем я соглашусь:
1) Действительно, с приходом move-семантики implicit sharing уже не выглядит так вкусно. Единственным аргументом в использовании implicit sharing сейчас является разве что его хорошая производительность из коробки, тогда как про move-семантику нужно всегда помнить и писать код соответствующе (к сожалению, до сих пор многие этим пренебрегают).
2) Действительно, я проверил, в qt3 не было атомарных операций при implicit sharing, что ломало счетчик в разных потоках. Только с Qt4 все стало нормально.
Но я не очень понял, как так получилось, что раньше так код работал, а потом, когда стало все нормально — перестал.
На самом деле обе реализации хранят внутри себя байты
Естественно. Только QString имеет представление о том, что она хранит, а std::string — нет.
Если же есть необходимость работать с отдельными символами юникода
Перегнать что-то из одной кодировки в другую — на самом деле, не такая уж и редкая проблема. Да, в мире, где казалось бы, уже везде используется UTF-8, все равно встречаются системы с какой-нибудь KOI8-R, и никто ничего переделывать не будет. Вот Qt позволяет такие вопросы решать из коробки очевидными способами.
А вот почему этого всего нет в стандарте — вопрос действительно хороший.
Вообще, отступая от темы, Qt исторически был вынужден изобретать велосипеды для каких-то ограниченных платформ
В первую очередь — из-за ограничений языка. Сейчас-то и moc уже не нужен, есть реализация от авторов оригинального moc'a чисто на шаблонной магии и новых стандартах. Я тоже надеюсь, что велосипеды будут потихоньку заменяться на стандарт, а новые фичи будут упрощать код. Но все же даже сегодня писать на Qt очень приятно и производительно.
Вопрос не только в собирается / не собирается, а в поддержке кода. Старый код на старом добром C++ (а чаще — на C с классами) может и собирается, но разобраться в нем зачастую боль и страдание.
только одна небезопасная реализация QString для потоков
Что значит эта фраза? QString реализует принцип CoW (Copy-On-Write), что, в общем-то, является одной из киллер-фич фреймворка, и позволяет практически безболезненно быстро гонять данные между потоками.
При этом, вместо того чтобы просто выкинуть QString в qt5, его продолжают тянуть в новые версии.
Кхм… у меня есть подозрения, что вы все-таки не очень разобрались с фреймворком. QString хранит внутри себя Unicode символы, а std::string — байты. В итоге QString знает, сколько хранит внутри себя символов, умеет гонять данные между разными кодировками, а также имеет удобное API, а std::string — не знает и не умеет. В итоге тот же lenght на UTF-8 данных вернет не количество символов, а размер в байтах.
Вообще, std::string корректнее сравнивать с QByteArray.
Не на всех платформах есть такое счастье, поэтому по умолчанию и отключено.
Насчет выкидывания Qt и переписывания на чистые плюсы и буст — если проект долгоиграющий, то это вам может аукнуться в будущем. Qt очень большой, слаженный, с отличным коммьюнити, огромным количеством примеров, понятным и логичным API. Неподготовленный пользователь может быстро стартануть с Qt.
А вот boost — уже для куда более подготовленных плюсовиков. И, к сожалению, не всегда такие есть под рукой.
Подтверждаю, тоже портировали с Qt 4.8 на тогда еще Qt 5.3 большой проект (~0.5 млн строк + библиотеки) — заняло пару дней. Исправления были минимальные, ничего не переписывали.
А экономика в первую очередь — скучное «чтобы было что кушать сегодня, завтра и послезавтра». Сливать деньги в никуда нетрудно, а в итоге добиться какого-то результата — финансового ли, научного — сложно.
Много исследований и денег идет на то, чтобы, например, сделать телефон более тонким, более быстрым, более легким, красивым и прочее, и прочее. Этот рынок живет, растет, пользуется спросом и приносит производителям много денег. В общем-то, это в какой-то степени хорошо. Но больше это не революция, телефоны плюс-минус все одинаковые, ими все пользуются, и можно довольно легко предугадать, что с ними будет через год, два, пять, десять лет — чуть быстрее, чуть тоньше, чуть дольше работать и т.д.
А речь о том, что реального R&D в новых областях очень мало. Бизнес не хочет (и часто — не может) рисковать. Для этого должно работать в том числе государство, выстраивать новую технологическую политику, политику в образовании, в работе. Международные связи и разработки (типа того же CERN). Происходит ровно обратное, замыкание на себя — это особо остро сейчас в России, но и более технологических странах такое тоже всплывает (США — Китай, например).
Потому что принципиально новое — это электромобиль. А ДВС со механической (да ещё и автоматической нередко теперь) трансмиссией — это больной с рождения выродок.
Я бы не был такой резок относительно ДВС, но опять же, нежелание слезать с золотой бочки крупных производителей авто привело к тому, что замена ДВС вот только-только начинает вырисовываться.
Ага, только опять же — поддерживать стек технологий атомной энергетики очень дорого.
В первую очередь им не занимаются, потому что сейчас это непопулярно. Политик, который захочет поставить в своем регионе АЭС — обречен.
Атомная энергетика дорога на старте — сложно строить, нужны специалисты, инфраструктура и т.д. В перспективе атомная энергетика оказывается дешевле и проще в обслуживании.
Одно из самых проблемных мест всяких ветряков — коэффициент используемой установленной мощности. АЭС всегда выдают расчетную мощность, ветряк — нет. В итоге мы приходим к тому, что ее где-то нужно накапливать, чтобы обеспечивать работу в утренние и вечерник пики, а это также дополнительная стройка, затраты, обслуживание и т.д.
Проблема в том, что сейчас R&D — это в первую очередь эффективное управление деньгам инвесторов, а не исследования новых, возможно, ложных путей развития, а от того более рискованных и дорогих.
Ваши примеры, кстати, отличное тому подтверждение. Автомобильный рынок сейчас — это большая беда. Все пытаются вставить в автомобиль всевозможные попограйки и вентиляции, а с такими важными узлами, как двигатель и коробка передач сейчас у каждого второго производителя проблемы. И только единицы компании пытаются построить что-то принципиально новое.
Ветроэнергетика по эффективности ни в какое сравнение с атомной не идет. Популяризации атомной энергетики нет, ее стали все боятся, политикам стало ее не выгодно поддерживать, вот мы и строим «ветряные мельницы». На самом деле, это очень дорого в строительстве и обслуживании и, на удивление многих людей, куда более деструктивно опасно для окружающей среды, чем АЭС.
Я хоть и особо не работаю с js, но вы все отлично оформили, приятно глазу посмотреть!
Глазу зацепилась таблица со сложностью для Hash Table. Все-таки среднее время поиска/вставки/удаления у нее будет константным, и только в худшем случае, если подобрана совсем неудачная хеш-функция, сложность будет линейная.
Ну дык я и написал, что на технической части обычно понятно, человек умеет решать задачи и просто боится бумагу, либо совсем мимо. Не в бумаге дело же.
Этого недостаточно. Посмотри (и проверь на чистой системе) размер полного деплоя, особенно для Qt5.
Я последний раз что-то на Винде разворачивал еще во времена активной жизни Qt4, и не припомню, чтобы размеры как-то впечатляли. Если открыть официальный мануал, то речь идет о 15-20мб (или +27, если с ICU) для mingw. Если msvc собрать, меньше будет.
Если мы говорим о никсах, то все нужные либки Qt, как правило, есть в системе, поэтому о размере вообще думать не приходится.
А шаблоны несущественно раздувают код.
Еще как раздувают. Какая-нибудь жирная либа на шаблонах типа CGAL сделает прогу уровня хеллоуворлд в несколько мегабайт на старте.
В целом, Кьют сравнимо с дНЕТ и вполне терпимо на сегодняшний день.
Ну, если мы деплоим на винду, то там, как правило, весь рантайм и либы (для минимального приложения) лежат в системе, поэтому бинарники весят очень мало. Зато на никсы деплоить дотнет — тот еще геморрой.
Ну так вы С++ с Qt не путайте с другими решениями (Delphi, Java и прочее).
Посмотрел, две базовые библиотеки Qt для окошек на моих никсах весят 4.5Мб (QtCore) и 6.5 (QtWidgets). Этого достаточно, чтобы быстро, надежно и без геморроя написать приложение с окошками.
Потом, Qt — не шаблонная библиотека, она не раздувает код. А также не тащит с собой виртуальные машины, райтаймы и т.д. Вот прям сейчас под рукой простенькое приложение на 10 окошек с сетью и БД занимает 300кБ в релизе. Размер смешной, чтобы его считать хоть сколько-то значимым.
Тут нужно правильно поставить приоритеты, что от чего идет. Если у нас уже есть UML схема, в которой, помимо прочего, есть конечные автоматы — да, проще и быстрее сгенерировать ее из того, что есть. Такое бывает, если система сначала проектируется, а потом создается (то есть в мире единорогов :) ).
Если же мы создаем какую-то систему, и нам нужен конечный автомат, то решение с SCXML будет более правильным. Лучше поддержка, есть множество готовых инструментов (как компиляторов, так и GUI-софтин). Ну и XML в наше время стандарт для многих систем, поддерживается всюду и везде.
Для описания конечного автомата есть стандарт SCXML. Для того, чтобы перегнать конечный автомат из этого формата в C++ код есть scxmlcc.
Также, в упомянутом вами Qt появился модуль Qt SCXML, который:
1) имеет компилятор qscxmlc;
2) позволят работать с SCXML прям в коде (грузить, сохранять, etc);
3) модуль для Qt Creator, который позволяет с помощью GUI рисовать свои конечные автоматы.
Не знаю, как там в штатах, но в России в default city ситуация простоя — есть много людей, которые вообще не написали ни строчки кода, но хотят устроиться джуниором за, условно, 100к/мес. При этом обучение такого «джуниора» — это, считай, наполнять чистый лист знаниями в течении нескольких лет. А результат не факт, что приведет к положительному эффекту.
Дело в том, что сейчас программирование — это хайп. Родители отдают своих детей «учиться программировать», не разбираясь, нравится это им или нет, есть ли у них талан и предрасположенность. В итоге получаем армию как бы выученных на разработку ПО людей, но по факту — притянутых за уши. Им это не интересно, они этим не особо хотят заниматься, но понимают, что за это платят деньги, поэтому что-то делать надо.
В итоге, когда приходят на собеседования студенты или совсем свежие выпускники, довольно быстро можно понять, стоит ли вообще тратить время на такого джуниора. Вот общаешься и понимаешь, что просто самый-самый потолок для этого человека, есть он будет что-то делать — middle. Он выучит это, это и вот это, но если шаг в сторону — «это не в моей компетенции, это я не знаю как, это я делать не буду». Я знаю, о чем говорю, такого много. Ну и зачастую нет смысла тратить время на такого джуна, если сколько-либо серьезных задач в будущем он все равно зарешать не сможет.
По моей статистике, только 1 из 10 джунов достойны внимания. То есть таких джунов, которым надо просто дорогу показывать, а дальше они сами все откопают, спросят, напишут. Они быстро станут мидлами, а потом, если их будет дальше переть, и сеньорами. Остальных надо тянуть за уши и вытирать за ними сопли без каких-либо перспектив получить качественный кадр.
У soci 2450 коммитов, последний был пару месяцев назад, сам проект уже черти когда назад начал писаться. На самом деле, продукт зрелый.
Еще в Qt4 это сделали. И надо сказать, что Qt4 появился аж в 2005 году, 13 лет назад. А это времена, когда никаких умных указателей и потоков в GCC не было, не говоря уж про msvc.
Qt3 — это 2001 год. К слову, первый интелловский двухядерный процессор Pentium D и амдешный Opteron появились только в 2005. И я не уверен, что там была отличная аппаратная поддержка атомарных операций (во всяком случае, компиляторы точно не умели правильно генерировать код). В тоже время, Qt3 имеет поддержку потоков (треды, мьютексы, conditional variable и прочее). И мне кажется, вы слишком много просите для того времени.
Конечно, нет. Строки в стандарте — это ужас. Вернее, как мы уже обсудили выше, строк как таковых в стандарте нет вообще.
QString::fromWCharArray
Опять же, Qt давно имеет эти классы, на них уже написано много кода, они хорошо, логично и удобно реализованы. Зачем ломать удобные классы, только лишь потому, что в стандарте недавно появилось аналогичное?
Я за то, чтобы заменить заведомо костыльные вещи на что-то новое и удобное. moc — замечательный костыль своего времени, но сейчас его можно реализовать элегантнее, не сломав старый код. Слоты в Qt5, благодаря лямбдам, стали намного удобнее и красивее. Вот я за такие изменения.
Кстати, на Qt чаще ругаются не когда они вводят что-то новое (за это наоборот все радуются), а когда они что-то удаляют. Как было, например, с перехода QtWebKit на QtWebEngine. Вот тут у людей были болезненные переходы.
И еще есть момент. Qt очень часто голым используется в embedded устройствах, прям минуя STL. Если памяти довольно мало, то практически всегда выгоднее тащить с собой QtCore с огромным функционалом из коробки, вместо довольно голого STL.
Ага, только wchar_t в винде занимает 2 байта, а в никсах — 4 байта. Со всеми вытекающими проблемами отсюда.
Все-таки внутри QString (да и вообще всех классов Qt, использующих implicit sharing) используются атомарные счетчики, а не стандартные блокирующие примитивы. Как только мы копируем объект, счетчик ссылок увеличивается на один, и мы получаем легкую копию (shallow copy). Если мы хотим изменить объект, вызывается detach и мы получаем глубокую копию (deep copy).
Так вот, если мы делаем копию строку в другом потоке, сначала получаем shallow копию, увеличиваем счетчик и работаем с shared данными. Как только мы начинаем изменять объект, мы получаем отвязанную локальную копию нашей строки, которая уже не ссылается на данные в других потоках. Ее изменение происходит локально, ничего нигде не сломается.
Совсем другое дело, если наша строка являются общей для разных поток, и они ее пытаются изменить. Да, тут нужны традиционные блокировки аля mutex, но это ровно также нужно и со всеми другими типами данных (то есть, аналогично нам нужно было бы сделать и с std::string). QString является реентерабельной функцией, не потокобезопасной.
Вообще, для решения такой проблемы (совместное изменение общих данных) разработчики рекомендуют использовать сигналы-слоты.
С чем я соглашусь:
1) Действительно, с приходом move-семантики implicit sharing уже не выглядит так вкусно. Единственным аргументом в использовании implicit sharing сейчас является разве что его хорошая производительность из коробки, тогда как про move-семантику нужно всегда помнить и писать код соответствующе (к сожалению, до сих пор многие этим пренебрегают).
2) Действительно, я проверил, в qt3 не было атомарных операций при implicit sharing, что ломало счетчик в разных потоках. Только с Qt4 все стало нормально.
Но я не очень понял, как так получилось, что раньше так код работал, а потом, когда стало все нормально — перестал.
Естественно. Только QString имеет представление о том, что она хранит, а std::string — нет.
Перегнать что-то из одной кодировки в другую — на самом деле, не такая уж и редкая проблема. Да, в мире, где казалось бы, уже везде используется UTF-8, все равно встречаются системы с какой-нибудь KOI8-R, и никто ничего переделывать не будет. Вот Qt позволяет такие вопросы решать из коробки очевидными способами.
А вот почему этого всего нет в стандарте — вопрос действительно хороший.
В первую очередь — из-за ограничений языка. Сейчас-то и moc уже не нужен, есть реализация от авторов оригинального moc'a чисто на шаблонной магии и новых стандартах. Я тоже надеюсь, что велосипеды будут потихоньку заменяться на стандарт, а новые фичи будут упрощать код. Но все же даже сегодня писать на Qt очень приятно и производительно.
Насчет UTF-16 — да, думаю, из-за винды. UTF-32 в винде почти нигде не используется, поэтому неудивительно, что выбрали средний вариант.
Что значит эта фраза? QString реализует принцип CoW (Copy-On-Write), что, в общем-то, является одной из киллер-фич фреймворка, и позволяет практически безболезненно быстро гонять данные между потоками.
Кхм… у меня есть подозрения, что вы все-таки не очень разобрались с фреймворком. QString хранит внутри себя Unicode символы, а std::string — байты. В итоге QString знает, сколько хранит внутри себя символов, умеет гонять данные между разными кодировками, а также имеет удобное API, а std::string — не знает и не умеет. В итоге тот же lenght на UTF-8 данных вернет не количество символов, а размер в байтах.
Вообще, std::string корректнее сравнивать с QByteArray.
Насчет выкидывания Qt и переписывания на чистые плюсы и буст — если проект долгоиграющий, то это вам может аукнуться в будущем. Qt очень большой, слаженный, с отличным коммьюнити, огромным количеством примеров, понятным и логичным API. Неподготовленный пользователь может быстро стартануть с Qt.
А вот boost — уже для куда более подготовленных плюсовиков. И, к сожалению, не всегда такие есть под рукой.
«Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.» ©
Много исследований и денег идет на то, чтобы, например, сделать телефон более тонким, более быстрым, более легким, красивым и прочее, и прочее. Этот рынок живет, растет, пользуется спросом и приносит производителям много денег. В общем-то, это в какой-то степени хорошо. Но больше это не революция, телефоны плюс-минус все одинаковые, ими все пользуются, и можно довольно легко предугадать, что с ними будет через год, два, пять, десять лет — чуть быстрее, чуть тоньше, чуть дольше работать и т.д.
А речь о том, что реального R&D в новых областях очень мало. Бизнес не хочет (и часто — не может) рисковать. Для этого должно работать в том числе государство, выстраивать новую технологическую политику, политику в образовании, в работе. Международные связи и разработки (типа того же CERN). Происходит ровно обратное, замыкание на себя — это особо остро сейчас в России, но и более технологических странах такое тоже всплывает (США — Китай, например).
Я бы не был такой резок относительно ДВС, но опять же, нежелание слезать с золотой бочки крупных производителей авто привело к тому, что замена ДВС вот только-только начинает вырисовываться.
В первую очередь им не занимаются, потому что сейчас это непопулярно. Политик, который захочет поставить в своем регионе АЭС — обречен.
Атомная энергетика дорога на старте — сложно строить, нужны специалисты, инфраструктура и т.д. В перспективе атомная энергетика оказывается дешевле и проще в обслуживании.
Одно из самых проблемных мест всяких ветряков — коэффициент используемой установленной мощности. АЭС всегда выдают расчетную мощность, ветряк — нет. В итоге мы приходим к тому, что ее где-то нужно накапливать, чтобы обеспечивать работу в утренние и вечерник пики, а это также дополнительная стройка, затраты, обслуживание и т.д.
Ваши примеры, кстати, отличное тому подтверждение. Автомобильный рынок сейчас — это большая беда. Все пытаются вставить в автомобиль всевозможные попограйки и вентиляции, а с такими важными узлами, как двигатель и коробка передач сейчас у каждого второго производителя проблемы. И только единицы компании пытаются построить что-то принципиально новое.
Ветроэнергетика по эффективности ни в какое сравнение с атомной не идет. Популяризации атомной энергетики нет, ее стали все боятся, политикам стало ее не выгодно поддерживать, вот мы и строим «ветряные мельницы». На самом деле, это очень дорого в строительстве и обслуживании и, на удивление многих людей, куда более деструктивно опасно для окружающей среды, чем АЭС.
Глазу зацепилась таблица со сложностью для Hash Table. Все-таки среднее время поиска/вставки/удаления у нее будет константным, и только в худшем случае, если подобрана совсем неудачная хеш-функция, сложность будет линейная.
Стабильность, огромный деплой, баги, глюки — это все не от прямых рук.
Я последний раз что-то на Винде разворачивал еще во времена активной жизни Qt4, и не припомню, чтобы размеры как-то впечатляли. Если открыть официальный мануал, то речь идет о 15-20мб (или +27, если с ICU) для mingw. Если msvc собрать, меньше будет.
Если мы говорим о никсах, то все нужные либки Qt, как правило, есть в системе, поэтому о размере вообще думать не приходится.
Еще как раздувают. Какая-нибудь жирная либа на шаблонах типа CGAL сделает прогу уровня хеллоуворлд в несколько мегабайт на старте.
Ну, если мы деплоим на винду, то там, как правило, весь рантайм и либы (для минимального приложения) лежат в системе, поэтому бинарники весят очень мало. Зато на никсы деплоить дотнет — тот еще геморрой.
Посмотрел, две базовые библиотеки Qt для окошек на моих никсах весят 4.5Мб (QtCore) и 6.5 (QtWidgets). Этого достаточно, чтобы быстро, надежно и без геморроя написать приложение с окошками.
Потом, Qt — не шаблонная библиотека, она не раздувает код. А также не тащит с собой виртуальные машины, райтаймы и т.д. Вот прям сейчас под рукой простенькое приложение на 10 окошек с сетью и БД занимает 300кБ в релизе. Размер смешной, чтобы его считать хоть сколько-то значимым.
Если же мы создаем какую-то систему, и нам нужен конечный автомат, то решение с SCXML будет более правильным. Лучше поддержка, есть множество готовых инструментов (как компиляторов, так и GUI-софтин). Ну и XML в наше время стандарт для многих систем, поддерживается всюду и везде.
Также, в упомянутом вами Qt появился модуль Qt SCXML, который:
1) имеет компилятор qscxmlc;
2) позволят работать с SCXML прям в коде (грузить, сохранять, etc);
3) модуль для Qt Creator, который позволяет с помощью GUI рисовать свои конечные автоматы.
Чем эти решения хуже/лучше вашего?
Дело в том, что сейчас программирование — это хайп. Родители отдают своих детей «учиться программировать», не разбираясь, нравится это им или нет, есть ли у них талан и предрасположенность. В итоге получаем армию как бы выученных на разработку ПО людей, но по факту — притянутых за уши. Им это не интересно, они этим не особо хотят заниматься, но понимают, что за это платят деньги, поэтому что-то делать надо.
В итоге, когда приходят на собеседования студенты или совсем свежие выпускники, довольно быстро можно понять, стоит ли вообще тратить время на такого джуниора. Вот общаешься и понимаешь, что просто самый-самый потолок для этого человека, есть он будет что-то делать — middle. Он выучит это, это и вот это, но если шаг в сторону — «это не в моей компетенции, это я не знаю как, это я делать не буду». Я знаю, о чем говорю, такого много. Ну и зачастую нет смысла тратить время на такого джуна, если сколько-либо серьезных задач в будущем он все равно зарешать не сможет.
По моей статистике, только 1 из 10 джунов достойны внимания. То есть таких джунов, которым надо просто дорогу показывать, а дальше они сами все откопают, спросят, напишут. Они быстро станут мидлами, а потом, если их будет дальше переть, и сеньорами. Остальных надо тянуть за уши и вытирать за ними сопли без каких-либо перспектив получить качественный кадр.