Прекрасно! Как подобного инструментария не хватало нам на 5.12-5.15: MapLibre появился только через год или был в зачаточном сотоянии - сейчас мощнейшая штука! Плюс ничего не знали про Bidirectional A* - сейчас бы наш алгоритм летал бы, всё было бы сильно проще и красивее. Спасибо!
В моём текущем проекте так и есть, но описывать не могу - NDA: Linux, QNX, куча целей, разные toolchain, сотни библиотек, в т.ч. свои закрытые. Однако это уже будет не статья, а большой учебник: вот, например, можно взять отличный учебник от Conan и вперёд: https://docs.conan.io/2/tutorial.html
Из живого есть только vcpkg и Buckaroo, но такого количества и качества поддержки, документации, сообщества, сопровождения, количества пакетов, поддерживаемых платформ, систем сборок и т.п. как у Conan пока не наблюдается и близко! Хотя у vcpkg тоже не слабая документация - тут MS на высоте.
Меня всегда удивляло как разработчики умудряются размещать большой объем вычислений на относительно слабом железе, к каким трюкам и решениям прибегают, чтобы приложение работало бысто, это относится не только к игровым движкам
Nintendo Switch - Постоянная внутренняя флеш-память: 32 ГБ (64 ГБ в Nintendo Switch OLED) Оперативная память - 4 ГБ (LPDDR4)
Это слабое железо?! Вот запихни это всё на БК-0010 с 64КБ памяти из них 32 КБ видеопамять!!! :D Вот что меня удивляло: ВОТ как ТУДА игры запихивали?! Причём не только "Клад", но и 3D игры, когда ты внутри авто и задача не впилиться в дерево! ;)
В моем бенчмарке исследуется вопрос производительности биндинга против присвоения через JS и C++
Я JS и С++ не сравнивал - не съезжайте с темы! Сравнивать бред - С++ будет на порядок быстрее. Сравнивается Binding и JS, а в ссылке про это всё есть:
It's slow. It delays errors that could be found at build time to run time, slowing down the development process. It overwrites any declarative binding that was in place. In most cases this is intended, but sometimes it can be unintentional. It interferes with tooling; Qt Quick Designer, for example, doesn't support JavaScript.
А функционал тоже выкидывался вместе с кодом?
Функционал полностью сохранялся и даже был лучше. Например выравнивание ширины ListView по макс элементу. У нас был деятель, который делал это через JS - уволили.
Еще бы хотелось узнать от Вас примеры "ухудшит архитектуру и расширяемость".
Этот момент также хорошо описан по ссылке выше. А по опыту выкидывание JS сокращало код в 2-3 раза минимум. Если логику держать в JS сразу возникают сложности с наследованием, декомпозицией, оптимизацией кода и т.п. Т.к. сразу в новые или декомпозированные элементы нужно сразу тащить весь JS код.
В соседнем лагере где HTML декларативный, JS - процедурный никого особо не смущает ничего :)
Ещё как смущает: HTML совершенно отличный от QML - там нет биндингов и машины конечных состояний. Т.е. без JS HTML не работает вообще - статичный полностью. Про сравнение производительности вообще молчу: Qt сравнивала не раз.
Большое количество биндингов и глубина цепочки этих самых биндингов также легко может стать причиной плохой производительности особенно на слабом железе поэтому не все так однозначно.
Возможно конечно, но я не сталкивался даже на слабом железе и с большим количеством биндингов. Но я говорю в сравнении: JS будет ещё хуже работать вне биндингов, будет гораздо менее производительным и значительно ухудшит архитектуру и расширяемость: QML декларативный, JS - процедурный. По моему опыту злоупотребление JS происходит от непонимания QML.
если у Вас дизайнеры/верстальщики участвуют в верстке QML такое вряд ли возможно,
Не участвуют и не должны.
присвоение свойств через оператор = в JS функциях обычная практика для сложного дизайна.
Это неправильно! Происходит от незнания и непонимания QML. Это очень сильно ухудшает производительность, увеличивает тех долг, сильно усложняет сопровождение и поддержку, ухудшает расширяемость кода и т.п. Плавали - знаем! Поэтому подобную практику пресекли на корню.
Прекрасно! Как подобного инструментария не хватало нам на 5.12-5.15: MapLibre появился только через год или был в зачаточном сотоянии - сейчас мощнейшая штука! Плюс ничего не знали про Bidirectional A* - сейчас бы наш алгоритм летал бы, всё было бы сильно проще и красивее. Спасибо!
Ещё бы тогда добавил Imaging Edge Desktop для Sony - топ!
Может потому, что он безплатный, имеет мощный функционал, а также то, что не все программы открывают сжатые RAW от Nikon.
Дополнения к минусам:
RawTherapee (и его форк ART), Darktable (LibRAW) пока не открывают Nikon-овские RAW, но скоро обещают научиться.
ФотоМАСТЕР - перспективно, цены приятные, но непонятно почему нет версии под Линукс.
digiKam попробовал - ужас! Интерфейс древний, особенно боковые панели, Nikon-овские фото не открывает также.
Плюсы:
Приятно порадовал просмотрщик PhotoQt - Linux, Mac, Windows - супер современный интерфейс, всё открывает, но не редактирует.
Интересно, но до конана пока не дотягивает: Nix runs on Linux and macOS.
А примеры кода как реализовано жалко привести?
В моём текущем проекте так и есть, но описывать не могу - NDA: Linux, QNX, куча целей, разные toolchain, сотни библиотек, в т.ч. свои закрытые. Однако это уже будет не статья, а большой учебник: вот, например, можно взять отличный учебник от Conan и вперёд: https://docs.conan.io/2/tutorial.html
Canon не может, а Conan может:
https://docs.conan.io/2/tutorial/consuming_packages/use_tools_as_conan_packages.html
Да можно (см. ссылку выше), в том то и смысл: можно использовать любой компилятор под любую платформу, что и сказано в начале.
Про всё во введении не расскажешь - статья увеличится в несколько раз.
Вот полный список: https://stackoverflow.com/a/36023212/630169
Из живого есть только
vcpkgиBuckaroo, но такого количества и качества поддержки, документации, сообщества, сопровождения, количества пакетов, поддерживаемых платформ, систем сборок и т.п. как у Conan пока не наблюдается и близко! Хотя уvcpkgтоже не слабая документация - тут MS на высоте.Да, с ним интереснее:
Тогда папку вывода указывать не нужно:
Тогда Conan и CMake файлы раскидываются по отдельным папкам и не мешаются с исполняемым файлом проекта.
На БК-0010 частота была 3 МГц :)))))))))))))))))))))
Nintendo Switch - Постоянная внутренняя флеш-память: 32 ГБ (64 ГБ в Nintendo Switch OLED)
Оперативная память - 4 ГБ (LPDDR4)
Это слабое железо?! Вот запихни это всё на БК-0010 с 64КБ памяти из них 32 КБ видеопамять!!! :D Вот что меня удивляло: ВОТ как ТУДА игры запихивали?! Причём не только "Клад", но и 3D игры, когда ты внутри авто и задача не впилиться в дерево! ;)
В цикле до 1000 - это смешно!
По ссылкАМ много примеров. Сравниваются подходы и принципы, а не примеры, которых может быть сотни.
Уволили не за это, а за многократное хамство и необучаемость как у вас.
Через биндинги parent<->child элементов.
Трёп у вас: я предоставил документацию Qt, которая есть квинтэссенция опыта, который совпадает с моим.
Я JS и С++ не сравнивал - не съезжайте с темы! Сравнивать бред - С++ будет на порядок быстрее. Сравнивается Binding и JS, а в ссылке про это всё есть:
Функционал полностью сохранялся и даже был лучше. Например выравнивание ширины ListView по макс элементу. У нас был деятель, который делал это через JS - уволили.
NDA
Вот ещё хорошая документация по теме:
Qt best practices:
Best Practices for QML and Qt Quick
Performance Considerations And Suggestions
Scalability
QML Application Structuring Approaches (some info is actual, some outdated)
А это ответ на ваш код:
B-6: Avoid Unnecessary Re-Evaluations
QML-Coding-Guide - вообще хорошая дока по стилю QML
Нет, мы этого делать не будем, а просто прочитаем документацию: Prefer Declarative Bindings Over Imperative Assignments
Этот момент также хорошо описан по ссылке выше. А по опыту выкидывание JS сокращало код в 2-3 раза минимум. Если логику держать в JS сразу возникают сложности с наследованием, декомпозицией, оптимизацией кода и т.п. Т.к. сразу в новые или декомпозированные элементы нужно сразу тащить весь JS код.
Ещё как смущает: HTML совершенно отличный от QML - там нет биндингов и машины конечных состояний. Т.е. без JS HTML не работает вообще - статичный полностью. Про сравнение производительности вообще молчу: Qt сравнивала не раз.
Возможно конечно, но я не сталкивался даже на слабом железе и с большим количеством биндингов. Но я говорю в сравнении: JS будет ещё хуже работать вне биндингов, будет гораздо менее производительным и значительно ухудшит архитектуру и расширяемость: QML декларативный, JS - процедурный. По моему опыту злоупотребление JS происходит от непонимания QML.
Не участвуют и не должны.
Это неправильно! Происходит от незнания и непонимания QML. Это очень сильно ухудшает производительность, увеличивает тех долг, сильно усложняет сопровождение и поддержку, ухудшает расширяемость кода и т.п. Плавали - знаем! Поэтому подобную практику пресекли на корню.
Кстати Qt и зависит от ICU.
Да, в Qt всё много проще!