Что бездоказательного в том, что доверяя владение другому лицу, ты больше ничего не можешь гарантировать? Внешние ссылки склонны умирать, устаревать и просто бесследно исчезать
Я знаю, почему так делать не надо) Так уж вышло, что я и сам немало времени провел в работе над этими бедами с зависимостями, я бы может и написал даже об этом статью, если бы она не сводилась к тому, что собственные велосипеды неизбежны, а чужие велосипеды вам не подойдут и зря вы читали эту статью)
Комментарием я просто хотел сказать, что выбор небольшой. Хранить рецепты централизованно больно, а распределенно нельзя, ибо результат будет эквивалентен отсутствию пакетного менеджера.
Если их не собирать в одном месте, то и гарантий собираемости не обеспечить. А если не обеспечить, то и зачем оно тогда нужно, просто банально проще идти старым путём
Выбор-то небольшой) Мы или пилим централизованно и одинаково, или оставляем всё как было)
Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)
Кто забыл? Я буквально вторым делом пишу "man <cmd>" при любой непонятке) Первым делом я спрашиваю ИИ :) Но они так часто врут и выдумывают флаги, что man всё ещё мой лучший друг)
Я сам лично писал на asm ещё 3 года назад, но я был такой один на всю компанию в 1500 человек. Ну, позже мне выдали ещё джуна и нас стало двое) Но в итоге вы вернулись к интринсикам, т.к. поддержка asm слишком неудобна оказалась.
И я пока не вижу зачем эти 5% продолжают писать на asm)
Я не припомню где бы си не справился) В этом мире даже самая распоследняя ручка имеет компилятор на Си)
Я помнится какой-то температурный датчик программировал, у него даже ассемблера не было, а компилятор на Си был) Компилировал он сразу в unsigned char массив, который ты хоть азбукой морзе загоняй по SPI внутрь этого контроллера)
Есть ровно один правильный путь - два телефона. Один для государства, другой для повседневных дел. Всё остальное полная фигня. Следующее же обновление следящего приложения найдет ещё какую-нибудь лазейку и вся информация об используемом VPN скомпроментирована.
Оберни циклы в лямбду и получишь ленивые вычисления) Буквально ценой пары скобочек)
Только в отличие от ranges, лямбду можно прикопать в std::function на всякий случай, если хочется. Как прикопать шаблонное месиво, которое плодят ranges - я не знаю)
Что бездоказательного в том, что доверяя владение другому лицу, ты больше ничего не можешь гарантировать? Внешние ссылки склонны умирать, устаревать и просто бесследно исчезать
Чем плох debian 13? Там свежие достаточно пакеты, свежее 24.04 убунты) Можно род "мятным соусом", есть Mint основанный на Debian
Я знаю, почему так делать не надо) Так уж вышло, что я и сам немало времени провел в работе над этими бедами с зависимостями, я бы может и написал даже об этом статью, если бы она не сводилась к тому, что собственные велосипеды неизбежны, а чужие велосипеды вам не подойдут и зря вы читали эту статью)
Комментарием я просто хотел сказать, что выбор небольшой. Хранить рецепты централизованно больно, а распределенно нельзя, ибо результат будет эквивалентен отсутствию пакетного менеджера.
Если их не собирать в одном месте, то и гарантий собираемости не обеспечить. А если не обеспечить, то и зачем оно тогда нужно, просто банально проще идти старым путём
Выбор-то небольшой) Мы или пилим централизованно и одинаково, или оставляем всё как было)
Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)
Но... Conan так умеет. А если чего-то не умеет, он довольно легко расширяется (ибо питончик).
Рецепты хранятся вместе с кодом, registry можно зеркалировать и поднимать свои
Ах если бы) ещё надо эту библиотеку в свою систему сборки вкорячить)
И слава богу! И пускай никогда не будет! Худшая фича С++! Сколько от неё страданий)
Сделали бы перегрузки допустимыми только для операторов - цены бы им не было.
И зачем они?
В том виде в котором она есть в С++ - нет. Но процедурные макросы ничем не хуже, а даже лучше.
Ну и С++26 ещё не приняли, в значит и в плюсах её тоже нет.
Кто забыл? Я буквально вторым делом пишу "man <cmd>" при любой непонятке) Первым делом я спрашиваю ИИ :) Но они так часто врут и выдумывают флаги, что man всё ещё мой лучший друг)
Я сам лично писал на asm ещё 3 года назад, но я был такой один на всю компанию в 1500 человек. Ну, позже мне выдали ещё джуна и нас стало двое) Но в итоге вы вернулись к интринсикам, т.к. поддержка asm слишком неудобна оказалась.
И я пока не вижу зачем эти 5% продолжают писать на asm)
Я не спорю, что всегда есть такое местечко, где ну вот вообще никак, хоть убей, но 300 строчек на асме надо написать)
Но сколько таких мест? И сколько надо программистов для них? И не справится ли LLM с этой задачей?)
Вопросы для меня не имеющие очевидного ответа, я просто не живу в мире настолько низкоуровневого программирования и не знаю никого, кто бы жил
Я не припомню где бы си не справился) В этом мире даже самая распоследняя ручка имеет компилятор на Си)
Я помнится какой-то температурный датчик программировал, у него даже ассемблера не было, а компилятор на Си был) Компилировал он сразу в unsigned char массив, который ты хоть азбукой морзе загоняй по SPI внутрь этого контроллера)
Но сколько нужно программистов для этого дела? 300 человек на весь мир?)
Есть ровно один правильный путь - два телефона. Один для государства, другой для повседневных дел. Всё остальное полная фигня. Следующее же обновление следящего приложения найдет ещё какую-нибудь лазейку и вся информация об используемом VPN скомпроментирована.
Да вполне обходятся. Практически все драйвера в Linux написаны на Си, без всяких ассемблерных вставок.
asm более или менее оправдан в крипте, да и то, на нем там не пишут, а прячут за кодогенерацией и/или макросами.
10 ms - это довольно много. За это время можно прилично трафика обработать)
Это не так, если ядра изолировать
Получится Rust) Ну, почти)
Да?
Но... Всё тоже самое можно сделать просто на композиции функций)
Оберни циклы в лямбду и получишь ленивые вычисления) Буквально ценой пары скобочек)
Только в отличие от ranges, лямбду можно прикопать в std::function на всякий случай, если хочется. Как прикопать шаблонное месиво, которое плодят ranges - я не знаю)