Есть ровно один правильный путь - два телефона. Один для государства, другой для повседневных дел. Всё остальное полная фигня. Следующее же обновление следящего приложения найдет ещё какую-нибудь лазейку и вся информация об используемом VPN скомпроментирована.
Оберни циклы в лямбду и получишь ленивые вычисления) Буквально ценой пары скобочек)
Только в отличие от ranges, лямбду можно прикопать в std::function на всякий случай, если хочется. Как прикопать шаблонное месиво, которое плодят ranges - я не знаю)
Не нужно сеть, не нужны парсеры, это вещи пользовательского домена.
Именно поэтому они есть в стандартной библиотеке... Вообще любого языка?)
Пакетных менеджеров хоть попой жуй
Пакетный менеджер один другого хуже) Хотя практически любой современный язык идёт комплектом с тулингом. "Жопой жуй" - это самый плохой сценарий. Это значит, что при смене места работы, заново учить очередные сборочные костыли. А это значит, что при необходимости добавить библиотеку снова придется приседать, склеивая ежа с ужом. Надоело.
Впрочем, зная комитет - соглашусь. Им такую задачу доверять нельзя. Сделают говно.
оставь рынку решить
С++ уже сколько лет? Ну даже если отсчитывать от первого стандарта - уже 28 лет. Нихрена рынок не может, это мы уже поняли)
Переносимые бинарники (можно запустить свою программу у друга)
Позволяет достаточно легко прыгнуть в Си, для желающих копаться "в кишочках", т.к. синтаксически похож, компилируемый и в целом есть unsafe, через который можно сделать "первое прикосновение"
Минусы конечно тоже есть, но по-моему неплохой кандидат.
Да не так, чтобы "хватает". Просто на текущий момент физически доступ быстрее не сделать к объёмам памяти больше, чем то, что есть.
Полно сценариев, где объем кэша недостаточен и хотелось бы побольше, просто ну вот никак. Увеличивая объем - приходится увеличивать скорость доступа и в какой-то момент достигается паритет между кэшом и RAM)
Compile time рефлексия С++26 не имеет ничего общего с рантайм рефлексией UE.
Первая нужна для генерации кода во время компиляции и обход полей класса "по порядку" не зная ничего о самом классе. Вторая для создания объектов "на лету" по их строковому описанию.
С++26 рефлексия полезна для замены сишных макросов и всякой ерунды, вроде обобщенного кода для сериализации/десериализации.
Абсолютно бессмысленно в рантайме, ведь после компиляции сгенерированные типы точно также ничего о себе не знают в рантайме.
Причин несколько, но все они сводятся к одному: "чертова физика, бессердечная ты с*ка".
Доступ к L1 кэшу должен быть мгновенный (1-5 тактов), иначе теряется смысл и можно ходить в память. Но чтобы доступ был мгновенный, нужно:
Иметь быстрый lookup (при увеличении размера - увеличивается время на поиск очевидно
Иметь физически короткие контакты (дорожки). Иначе на частотах 4-5 ГГц, сигнал тупо не дойдёт за 1 такт, а это увеличивает latency. Речь о расстоянии в миллиметры и меньше, но можете сами посчитать сколько сигнал успеет пройти на такой частоте.
Иметь разумное энергопотребление, и что важнее, тепловыделение, т.е. нельзя располагать память слишком плотно. Косвенно опять же связано с размером самой дорожки.
Плюс всё это не должно стоить слишком дорого. Некоторое время, на заре времён, экспериментировали с размерами L1 кэша, его ассоциативностью и прочим. Выяснилось, что 16кб - слишком мало. 64кб - слишком долгий доступ и греется зараза.
32-48 кб - оптимально. Так и повелось. По крайней мере для x86_64. Впрочем, и сейчас есть чипы с бОльшим количеством L1 кэша, у тех же Apple M-серии вроде что-то порядка 192 КБ. Если честно не вникал как они этого достигли, но вон чатгпт говорит что latency там все равно большой, физически архитектура сильно сложнее получилась, а компенсируется latency большим пайплайном исполнения.
если ваш шебанг вдруг окажется ... #!/bin/sh вместо #!/bin/bash
Ну... если вы пишете bash-скрипт, то и shebang надо указывать правильный)
А ещё нередко встречается busybox в эмбеде, там тоже ash
Да, это возможный сценарий, но том эмбеде, в котором нет bash, на шелл-скриптах особо и не пишут ничего большого.
А ещё нередко в прод ставят контейнеры, в которых до предела минимизируют окружение.
В таких контейнерах никогда шелл-скрипты и не запускают. В них упаковывают одну программу на каком-нибудь go и её же и запускают.
А иногда даже бывает нужна совместимость с zsh
Проще написать две версии скриптов автокомплита, т.к. у zsh вообще своя магия для комплита.
Это не всегда решает автор скрипта
Автору ничего решать и не надо) Автор пишет в шебанге условный #!/usr/bin/env bash, а остальное - проблемы пользователя)
Я не буду отрицать - сценарии где bash недоступен - существуют. Я лишь хочу сказать, что я с такими не сталкивался за 20 лет ни разу. Да, наверное в initramfs нет bash, но если мне придётся там много скриптовать - я просто его туда упакую.
Но сколько нужно программистов для этого дела? 300 человек на весь мир?)
Есть ровно один правильный путь - два телефона. Один для государства, другой для повседневных дел. Всё остальное полная фигня. Следующее же обновление следящего приложения найдет ещё какую-нибудь лазейку и вся информация об используемом VPN скомпроментирована.
Да вполне обходятся. Практически все драйвера в Linux написаны на Си, без всяких ассемблерных вставок.
asm более или менее оправдан в крипте, да и то, на нем там не пишут, а прячут за кодогенерацией и/или макросами.
10 ms - это довольно много. За это время можно прилично трафика обработать)
Это не так, если ядра изолировать
Получится Rust) Ну, почти)
Да?
Но... Всё тоже самое можно сделать просто на композиции функций)
Оберни циклы в лямбду и получишь ленивые вычисления) Буквально ценой пары скобочек)
Только в отличие от ranges, лямбду можно прикопать в std::function на всякий случай, если хочется. Как прикопать шаблонное месиво, которое плодят ranges - я не знаю)
Именно поэтому они есть в стандартной библиотеке... Вообще любого языка?)
Пакетный менеджер один другого хуже) Хотя практически любой современный язык идёт комплектом с тулингом. "Жопой жуй" - это самый плохой сценарий. Это значит, что при смене места работы, заново учить очередные сборочные костыли. А это значит, что при необходимости добавить библиотеку снова придется приседать, склеивая ежа с ужом. Надоело.
Впрочем, зная комитет - соглашусь. Им такую задачу доверять нельзя. Сделают говно.
С++ уже сколько лет? Ну даже если отсчитывать от первого стандарта - уже 28 лет. Нихрена рынок не может, это мы уже поняли)
Добавить сеть
Добавить приличные парсеры популярных текстовых форматов
Выкинуть всё говно, которое наворотили со строками и сделать по-человечески. Заколебало везде за собой таскать ICU.
Запретить устаревший синтаксис (хоть те же "эпохи" ввести)
Стандартизировать ABI
Хочется стандартный пакетный менеджер
Интрузивные контейнеры
Стандартизировать отключение исключений
Но в целом, С++ уже ничего не поможет) Он слишком многословный и хрупкий) Его придётся любить таким, какой он есть
От ответа теперь только больше вопросов:)
По какой памяти? Что значит "проезд"? Зачем мне вообще ranges, если они такое говно?)
А проблема-то в чём?)
Чем плох go для старта обучения?
Он относительно простой.
Достаточно низкоуровневый если захотеть
Используется в реальной жизни
Богатый тулинг для дальнейшего развития
Переносимые бинарники (можно запустить свою программу у друга)
Позволяет достаточно легко прыгнуть в Си, для желающих копаться "в кишочках", т.к. синтаксически похож, компилируемый и в целом есть unsafe, через который можно сделать "первое прикосновение"
Минусы конечно тоже есть, но по-моему неплохой кандидат.
Microsoft нынче разрабатывает PowerToys. Это эдакий швейцарский нож из ништяков, без которых мне уже и винда - не винда. Там есть аналог unlocker
Да не так, чтобы "хватает". Просто на текущий момент физически доступ быстрее не сделать к объёмам памяти больше, чем то, что есть.
Полно сценариев, где объем кэша недостаточен и хотелось бы побольше, просто ну вот никак. Увеличивая объем - приходится увеличивать скорость доступа и в какой-то момент достигается паритет между кэшом и RAM)
Compile time рефлексия С++26 не имеет ничего общего с рантайм рефлексией UE.
Первая нужна для генерации кода во время компиляции и обход полей класса "по порядку" не зная ничего о самом классе. Вторая для создания объектов "на лету" по их строковому описанию.
С++26 рефлексия полезна для замены сишных макросов и всякой ерунды, вроде обобщенного кода для сериализации/десериализации.
Абсолютно бессмысленно в рантайме, ведь после компиляции сгенерированные типы точно также ничего о себе не знают в рантайме.
Причин несколько, но все они сводятся к одному: "чертова физика, бессердечная ты с*ка".
Доступ к L1 кэшу должен быть мгновенный (1-5 тактов), иначе теряется смысл и можно ходить в память. Но чтобы доступ был мгновенный, нужно:
Иметь быстрый lookup (при увеличении размера - увеличивается время на поиск очевидно
Иметь физически короткие контакты (дорожки). Иначе на частотах 4-5 ГГц, сигнал тупо не дойдёт за 1 такт, а это увеличивает latency. Речь о расстоянии в миллиметры и меньше, но можете сами посчитать сколько сигнал успеет пройти на такой частоте.
Иметь разумное энергопотребление, и что важнее, тепловыделение, т.е. нельзя располагать память слишком плотно. Косвенно опять же связано с размером самой дорожки.
Плюс всё это не должно стоить слишком дорого. Некоторое время, на заре времён, экспериментировали с размерами L1 кэша, его ассоциативностью и прочим. Выяснилось, что 16кб - слишком мало. 64кб - слишком долгий доступ и греется зараза.
32-48 кб - оптимально. Так и повелось. По крайней мере для x86_64. Впрочем, и сейчас есть чипы с бОльшим количеством L1 кэша, у тех же Apple M-серии вроде что-то порядка 192 КБ. Если честно не вникал как они этого достигли, но вон чатгпт говорит что latency там все равно большой, физически архитектура сильно сложнее получилась, а компенсируется latency большим пайплайном исполнения.
Исключение вполне себе может вылететь при рядовых операциях)
Ну... если вы пишете bash-скрипт, то и shebang надо указывать правильный)
Да, это возможный сценарий, но том эмбеде, в котором нет bash, на шелл-скриптах особо и не пишут ничего большого.
В таких контейнерах никогда шелл-скрипты и не запускают. В них упаковывают одну программу на каком-нибудь go и её же и запускают.
Проще написать две версии скриптов автокомплита, т.к. у zsh вообще своя магия для комплита.
Автору ничего решать и не надо) Автор пишет в шебанге условный
#!/usr/bin/env bash, а остальное - проблемы пользователя)Я не буду отрицать - сценарии где bash недоступен - существуют. Я лишь хочу сказать, что я с такими не сталкивался за 20 лет ни разу. Да, наверное в initramfs нет bash, но если мне придётся там много скриптовать - я просто его туда упакую.