У меня аналогичный defer уже как много лет на 11 стандарте работал на многих моих проектах. Условный дефер не нужен, так как условие можно внутри блока написать. Поэтому не вижу смысла показывать что это лямбда. Семантика defer и так максмально прозрачна и понятна.
Также могу порекомендовать свою поделку muenvsubst (пост о ней тут https://habr.com/ru/posts/904586/), которая была изначально придумана как более продвинутая замена envsubst с шаблонизатором на базе mustache, но потом была переписана на ещё более продвинутый шаблонизатор аналогичный Jinja.
Ну пока не вижу преимуществ перед просто передачей параметров в конструктор, без библиотек. Возможно под Android с Activity это и необходимо. Но при серверной разработке спокойно можно обойтись и без этих библиотек.
Да уж. Сменить нормальный андроид на убогий yaos без хромкаста, это они будут самоубийцы если примут предложение Яндекса. Маломальски технически подкованные люди не будут покупать это.
Это только про сам креатор. А там в докере ещё можно настроить и все необходимое окружение, определенную версию операционки, необходимые devel пакеты, возможно какие-то вспомогательные сервисы, типа постгрес или кейклок.
Ещё, как вариант, в докере можно поднять Xvnc, простенький рабочий стол с IceWM или чем-то подобным, получается практически виртуалка. А если ещё прикрутить к этому NoVnc (https://github.com/navrocky/novnc-docker) то вообще можно из браузера туда ходить, работать удалённо.
Красивое из коробки отображение QString и прочих кутешных классов в отладчике (в vscode есть конечно возможность подгрузить преттипринтеры для Qt). QML и Widgets дизайнер. Дополнение в QML коде. Удобная сборка и деплой приложения под Андроид. Это я навскидку вспомнил..
В креаторе уже есть зачаточная поддержка разработки в докере, аналог дев контейнеров. Год назад я это щупал. Не знаю насколько продвинулись в этом направлении.. Если допилят до состояния как в VSCode, тогда можно будет не изобретать такое.
Надеюсь в следующих частях увидеть как для этой библиотеки настроить пайплайн на github, со сборкой релизов и публикацией в conan. По мне это одна из самых главных фишек библиотек, если она есть в package менеджерах - её будут использовать намного чаще.
Я после долгих лет использования различных сервис локаторов от ВАУ какая штука пришел к пониманию что лучше жить без них. Основная проблема в сервис локаторах заключается в том, что мы перекладываем проверку корректности конфигурирования зависимостей нашего приложения на рантайм. Если по старинке создавать все объекты в образном main и передавать им все зависимости в конструкторе, то проверкой, всё ли мы передали, будет заниматься компилятор. И не будет ситуации, когда работающее приложение в какой-то момент вылетает, потому что lazy зависимость не удовлетворена.
И не нужны никакие библиотеки. Если нужен синглтон - передаешь в конструктор созданную зависимость, если нужна фабрика, передаёшь в конструктор функцию создания.
Сколько пафоса ) А вот с английским языком в описании надо поработать...
Раньше тоже использовал BOOST_SCOPE_EXIT, пока не появился 11 стандарт. Затем написал свой велосипед аналогичный этому defer. Так как это удобно.
У меня аналогичный defer уже как много лет на 11 стандарте работал на многих моих проектах. Условный дефер не нужен, так как условие можно внутри блока написать. Поэтому не вижу смысла показывать что это лямбда. Семантика defer и так максмально прозрачна и понятна.
Именно чтобы меньше буков писать и нужны макросы.
Не совсем понимаю в чем реализация полагается на C++17, тут C++11 должно быть достаточно.
И ещё можно улучшить, затащив [&] внутрь макроса, тогда можно будет писать почти как в Go:
defer { close(file); };Также могу порекомендовать свою поделку muenvsubst (пост о ней тут https://habr.com/ru/posts/904586/), которая была изначально придумана как более продвинутая замена envsubst с шаблонизатором на базе mustache, но потом была переписана на ещё более продвинутый шаблонизатор аналогичный Jinja.
Ну тут сложно ) правильного наверное нет
Вкусно и точка )
Интересно, сколько пользователей было у этого дистра? Ну точно 1 был - автор..
А есть ли какие-то готовые устройства? Мне такой нужен, чтобы счет в игре (волейбол, баскетбол) в зале проецировать на стену
Ну пока не вижу преимуществ перед просто передачей параметров в конструктор, без библиотек. Возможно под Android с Activity это и необходимо. Но при серверной разработке спокойно можно обойтись и без этих библиотек.
Да уж. Сменить нормальный андроид на убогий yaos без хромкаста, это они будут самоубийцы если примут предложение Яндекса. Маломальски технически подкованные люди не будут покупать это.
Это только про сам креатор. А там в докере ещё можно настроить и все необходимое окружение, определенную версию операционки, необходимые devel пакеты, возможно какие-то вспомогательные сервисы, типа постгрес или кейклок.
Ещё, как вариант, в докере можно поднять Xvnc, простенький рабочий стол с IceWM или чем-то подобным, получается практически виртуалка. А если ещё прикрутить к этому NoVnc (https://github.com/navrocky/novnc-docker) то вообще можно из браузера туда ходить, работать удалённо.
Красивое из коробки отображение QString и прочих кутешных классов в отладчике (в vscode есть конечно возможность подгрузить преттипринтеры для Qt). QML и Widgets дизайнер. Дополнение в QML коде. Удобная сборка и деплой приложения под Андроид.
Это я навскидку вспомнил..
Ну вы же в курсе вот этого? https://marketplace.visualstudio.com/items?itemName=TheQtCompany.qt-ui
В креаторе уже есть зачаточная поддержка разработки в докере, аналог дев контейнеров. Год назад я это щупал. Не знаю насколько продвинулись в этом направлении.. Если допилят до состояния как в VSCode, тогда можно будет не изобретать такое.
Надеюсь в следующих частях увидеть как для этой библиотеки настроить пайплайн на github, со сборкой релизов и публикацией в conan. По мне это одна из самых главных фишек библиотек, если она есть в package менеджерах - её будут использовать намного чаще.
Я после долгих лет использования различных сервис локаторов от ВАУ какая штука пришел к пониманию что лучше жить без них. Основная проблема в сервис локаторах заключается в том, что мы перекладываем проверку корректности конфигурирования зависимостей нашего приложения на рантайм. Если по старинке создавать все объекты в образном main и передавать им все зависимости в конструкторе, то проверкой, всё ли мы передали, будет заниматься компилятор. И не будет ситуации, когда работающее приложение в какой-то момент вылетает, потому что lazy зависимость не удовлетворена.
И не нужны никакие библиотеки. Если нужен синглтон - передаешь в конструктор созданную зависимость, если нужна фабрика, передаёшь в конструктор функцию создания.
Ещё есть
ncdu(https://linux.die.net/man/1/ncdu) которая присутствует во многих дистрибутивах.