Значительная часть моих знакомых и друзей занимаются профессиональной разработкой на C++. При знакомстве с кодом некоторых Python-программ у них возникают вопросы типа: "Почему в Python так часто используется try-except блок? Неужели это не создает дополнительных расходов для интерпретатора?"
Видимо, они не в курсе что в том-же C++ механизм исключений настолько хорошо отлажен и оптимизирован что практически не создаёт дополнительных расходов...
К вашему вкусу претензий нет. Вопросики к: "Half-Life 2 я не ждал, и мне он не понравился, так как визуально выглядел игрой из прошлого, без новых технологий. "
А как быть если у меня мой кастомный плагин, подключённый в основной проект, содержит файл app-common.gradle.kts в котором прописаны общие элементы конфигурации (например, общие зависимости, версия SDK и т.д.) и который, в свою очередь, подключается в подпроекты основного проекта как плагин. Что делать если в этом app-common.gradle.kts я хочу тоже использовать libs.versions.toml ?
А как быть если у меня мой кастомный плагин, подключённій в основной проект, содержит файл app-common.gradle.kts в котором прописаны общие элементы конфигурации (например, общие зависимости, версия SDK и т.д.) и который, в совю чоередь, подключается в подпроекты основного проекта как плагин. Что делать если в этом app-common.gradle.kts я хочу тоже использовать libs.versions.toml ?
Хотите - минусуйте, но я обязан пошутить:
Когда не взяли в ядро Linux, ба-дум-тсс
Хуже только функциональное программирование головного мозга)
Разве std::ranges не призваны, в том числе, решить и данную проблему?
Очень сильно сомневаюсь что упомянутые вами свойства присущи обычной зарядке, упомянутой выше, давайте не придумывать на ходу
У вас в розетке постоянный ток?!))
Или на зарядке подписано где должна быть фаза, а где ноль?))
А миска рис и кошка жена давать будут? Партия гордится?!
Не повернётся. Не выделят
Видимо, они не в курсе что в том-же C++ механизм исключений настолько хорошо отлажен и оптимизирован что практически не создаёт дополнительных расходов...
А вы уверены что каждый принтер и каждое чернило будет иметь один и тот-же оттенок ,я вот - нет)
Аффтар жжот
Статья показывает качество продукта, так сказать. Костыли из 2010-х всё ещё удачно эксплуатируемы в 2020-х спустя 15 лет))
К вашему вкусу претензий нет. Вопросики к: "Half-Life 2 я не ждал, и мне он не понравился, так как визуально выглядел игрой из прошлого, без новых технологий. "
Может у вас автоочистка где настроена? Ни разу такого не случалось ни на десктопе, ни на смартфоне
Глупости. Это разве похоже на вызов через точку? Ни разу т.к. в плюсах нежелательно перегружать оператор "точка"
И плюс, в плюсах нет возможности последний аргумент являющийся лямбдой вынести за круглые скобки и не писать их вообще:
func(lambda)vs
func { /*lambda body goes here */ }Как по мне, намного более удобная фича Kotlin, которой мне не хватает в C++ - это чейн-функции вида also/apply/let/run/ ...
Ого, это что, адепты безопасного Rust агитируют небезопасно делать к области памяти небезопасного C++ в надежде что ничего не поломается?
Совершенно верно
Всё, простите, вопрос снимается, вторая часть статьи помогла решить его
А как быть если у меня мой кастомный плагин, подключённый в основной проект, содержит файл app-common.gradle.kts в котором прописаны общие элементы конфигурации (например, общие зависимости, версия SDK и т.д.) и который, в свою очередь, подключается в подпроекты основного проекта как плагин. Что делать если в этом app-common.gradle.kts я хочу тоже использовать libs.versions.toml ?
Т.е. структура такая:
Пока "радует" меня такой ошибкой:
Unresolved reference: libsА как быть если у меня мой кастомный плагин, подключённій в основной проект, содержит файл app-common.gradle.kts в котором прописаны общие элементы конфигурации (например, общие зависимости, версия SDK и т.д.) и который, в совю чоередь, подключается в подпроекты основного проекта как плагин. Что делать если в этом app-common.gradle.kts я хочу тоже использовать libs.versions.toml ?
Пока "радует" меня такой ошибкой:
Unresolved reference: libs