Обновить
2
Алексей@Tantrido

Старший программист C++/Qt/C#/.Net/Node.js

6
Подписчики
Отправить сообщение

UI через С++ - это каменный век! Там UI не через процедурный JS (некоторые не разобравшись злоупотребляют им). Открой для себя красоту декларативного QML: я после него на ужас архитектуры Qt Widgets вернуться не захотел.

После выхода C++26 я понял, что должен сделать то же самое, но на «плюсах».

Открой для себя Qt - мы там давно это делаем и именно на плюсах и без всякого питона ;-)

Хорошо бы в табличку и в окончательные выводы добавить C++14 и C++98, потому, что он был сильно проще в то время, но и тогда картина применительно к прикладной области была схожая.

Интересно, а в conan есть для heic готовые рецепты, чтобы избежать всех этих танцев с бубном?!

Похоже что-то есть:

Более-менее стабильный Promise появился в версии Qt 5.15.

Что-то припоминаю, но не пользовался.

Не знал, что QML реализация JS поддерживает промисы.

Прекрасно! Как подобного инструментария не хватало нам на 5.12-5.15: MapLibre появился только через год или был в зачаточном сотоянии - сейчас мощнейшая штука! Плюс ничего не знали про Bidirectional A* - сейчас бы наш алгоритм летал бы, всё было бы сильно проще и красивее. Спасибо!

Ещё бы тогда добавил Imaging Edge Desktop для Sony - топ!

Не понятно, что в обзоре делает проявщик от Nikon.

Может потому, что он безплатный, имеет мощный функционал, а также то, что не все программы открывают сжатые 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 может сам установить, скажем, clang?

Canon не может, а Conan может:
https://docs.conan.io/2/tutorial/consuming_packages/use_tools_as_conan_packages.html

То есть могу я указать clang в списке зависимостей (подобно как в данной статье в качестве зависимости указан SQLite)?

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

Почему во всех статьях предполагается, что в системе уже установлен toolchain?.

Про всё во введении не расскажешь - статья увеличится в несколько раз.

Вот полный список: https://stackoverflow.com/a/36023212/630169

Из живого есть только vcpkg и Buckaroo, но такого количества и качества поддержки, документации, сообщества, сопровождения, количества пакетов, поддерживаемых платформ, систем сборок и т.п. как у Conan пока не наблюдается и близко! Хотя у vcpkg тоже не слабая документация - тут MS на высоте.

Да, с ним интереснее:

[layout]
cmake_layout

Тогда папку вывода указывать не нужно:

conan install . --build=missing
cd build
cmake .. -G Ninja -DCMAKE_TOOLCHAIN_FILE="./Release/generators/conan_toolchain.cmake" -DCMAKE_BUILD_TYPE=Release
ninja

Тогда Conan и CMake файлы раскидываются по отдельным папкам и не мешаются с исполняемым файлом проекта.

На БК-0010 частота была 3 МГц :)))))))))))))))))))))

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

Nintendo Switch - Постоянная внутренняя флеш-память: 32 ГБ (64 ГБ в Nintendo Switch OLED)
Оперативная память - 4 ГБ (LPDDR4)

Это слабое железо?! Вот запихни это всё на БК-0010 с 64КБ памяти из них 32 КБ видеопамять!!! :D Вот что меня удивляло: ВОТ как ТУДА игры запихивали?! Причём не только "Клад", но и 3D игры, когда ты внутри авто и задача не впилиться в дерево! ;)

В моих тестах есть и такое сравнение и разница в скорости смешная.

В цикле до 1000 - это смешно!

По ссылке рассматривается

По ссылкАМ много примеров. Сравниваются подходы и принципы, а не примеры, которых может быть сотни.

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

Уволили не за это, а за многократное хамство и необучаемость как у вас.

А как стали делать без JS?

Через биндинги parent<->child элементов.

Трёп у вас: я предоставил документацию Qt, которая есть квинтэссенция опыта, который совпадает с моим.

В моем бенчмарке исследуется вопрос производительности биндинга против присвоения через 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 - уволили.

Тоже неясно без кода ничего.

NDA

1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность