Для битовых массивов и множества алгоритмов с ними есть и много лет развивается BitMagic С++ от Анатолия Кузнецова github.com/tlk00/BitMagic, который содержит оптимизации под SSE, AVX, Neon инструкции.
Очень жаль. Это был единственный хорошо для клиентов работающий конкурент яндубера в экономе в окрестностях дефолт-сити, которым доводилось пользоваться раза в 2 чаще остающегося теперь монополиста.
Сотовые операторы обычно не занимаются подключением удалённых оконечных пользователей вне зоны покрытия. Фемтосота от оператора с интересным ему потенциалом подключить не только одинокий компьютер с дополнительной онлайн-кассой выйдет сильно дороже Старлинка, ведь к ней надо тоже сигнал дотянуть либо кабелем, либо радиорелейкой. Пока что их позволяют себе только гораздо более крупные бизнесы, чем магазин в глухой деревне без покрытия от большой четвёрки.
Буква «О» в аббревиатуре «SOLID» постоянно пролетает мимо? Да и другие буквы тоже как-то не выживают в этом гипотетическом проекте, где 100 файлов зависят от одного, который ежедневно и ежечасно правят.
SOCKS-протокол реализует Danted на хостинге. Задача ssh клиента только пробросить через SSH подключение локальный порт (в примере 1080) на открытый порт Danted на удалённой машине.
Проблема там не в том, что занято, оператор перегрузить можно в C++, а в том, что у операции возведения в степень в математике самый высокий приоритет, а в C/C++ у хоr — очень низкий. 5+6^7 == 5 + (6^7) в математике, но 5+6^7 == (5 + 6)^7 в C/C++.
Было бы интересно, если бы заодно с перегрузкой операторов давали перегружать operator precedence…
Эта история чем-то похожа на историю с многомерными индексами. Ради них в C++20 «сломали» другой оператор — запятую. До С++20 этот оператор не работал только в вызовах функций и в списках инициализации, а в C++20 он перестал работать ещё и в вызове оператора [], т.е. по C++17 можно было написать a[b=1, c]=1 эквивалентное {b=1; a[c]=1;} начиная с C++20 для этого же стало нужно писать a[(b=1, c)]=1; а начиная с С++23 выражение a[b=1, c]=1 будет означать {b=1; a[b][c]=1}.
Это невозможно, к сожалению. Разработчики компиляторов выкатывают разные фичи стандартов как задолго до их утверждения, так и много позже. Более того, сам компилятор может уже поддерживать все фичи стандарта, а библиотеки с ним — всё ещё нет. Например, стандарт С++11 сказал, что std::list::size() должен иметь сложность O(1), gcc 4.8 начал полностью поддерживать С++11, а в std::list::size() продолжал иметь сложность O(N) (RHEL7/CentOS7 с таким gcc поставлялись).
Вероятно, DNS серверы провайдера просто легли от массовых запросов от всех FB приложений его клиентов, которые ожесточённо пытались найти дорогу домой.
Для отказоустойчивости надо иметь DNS в разных ASN, которые должны управляться отдельно, т.е. так, чтобы такие проблемы с BGP анонсами не становились глобальными.
Полные пути от корня ФС, а не от корня проекта выглядят ужасно. Мы в своём не очень большом проекте через constexpr функции вытаскиваем чистые имена файлов исходников без путей из __FILE__, чтобы не писать эти простыни при логировании, не тащить их в ёлку и т.д. Для большого проекта было бы актуальнее вытащить путь от его корня. Для stacktraces придётся патчить компилятор?
Было бы интересно, если бы заодно с перегрузкой операторов давали перегружать operator precedence…
Эта история чем-то похожа на историю с многомерными индексами. Ради них в C++20 «сломали» другой оператор — запятую. До С++20 этот оператор не работал только в вызовах функций и в списках инициализации, а в C++20 он перестал работать ещё и в вызове оператора [], т.е. по C++17 можно было написать a[b=1, c]=1 эквивалентное {b=1; a[c]=1;} начиная с C++20 для этого же стало нужно писать a[(b=1, c)]=1; а начиная с С++23 выражение a[b=1, c]=1 будет означать {b=1; a[b][c]=1}.