Игнорируйте всё, что я сказал выше, в Chants of Sennaar можно погладить кошку, всё, это игра десятилетия.

fxtwitter.com/CanYouPetTheDog/status/1704198156940943558

Итак друзья, вопрос к вам (но только тем, кто не пишет на Rust), как вы в своём языке напишите код, аналогичный следующему?

        if let Ok(collection) = Collection::try_from((collection_metadata, traits)) {
            result.push(collection);
        }

Разъясню что он делает. В случае, если у нас не получилось сконвертировать метаданные коллекции и её типажи, мы не делаем ничего. Если же оперция прошла успешно, мы добавляем её результат в коллекцию.

#prog #rust #rustlib

Я противник того, чтобы доходить до максимума в вопросах копирования кода. Неверная абстракция обычно намного дороже чем копи паста. Однако есть моменты, которые хочется оптимизировать. Например трассировка вызовов методов и их инструментация.

Для этого я пользуюсь instrument атрибутом от tracing библиотеки. Каждая важная функция имеет плашечку инагента :

#[instrument(err(Debug), skip(executor), ret, level = "trace")]
fn insert(...) -> Result<...> { ...

Но есть проблема, каждый раз писать схожие аннотации, вспоминая точный синтаксис, это бывает утомительно и точно непродуктивно. Как же я был сегодня рад найти молодую утилиту для моего #toolkit — attr_alias.

Как же её готовить? Создавайте файл src/attr-aliases.txt (даже если у вас workspace — я думаю скоро я или автор поправим это) и пишите в нём алиас, я написал: *db_instrument=instrument(err(Debug), skip(executor), ret, level = "trace")

Далее — идём в код и используем его:

    #[attr_alias(db_instrument)]
    pub async fn select_...<'a, E>(...: &str, executor: E) -> Result<...>

Вуаля, теперь я могу использовать маленький алиас вместо грузного объявления всего, что мне нужно.

А ещё у этой утилиты нет зависимостей, кроме стандартной библиотеки Rust. Очень котирую и всем советую. Дай бог поменьше зависимостей, да будут мои билды быстрыми, аминь 🧎🤲

Вопрос «Что происходит, когда пользователь вводит URL в браузере?» мы на собеседованиях больше НЕ задаём.

Кандидат сегодня был очень напористый. Он поставил себе цель рассказать вообще всё!

За первые 20 минут он рассказал, как сигналы с клавиатуры передаются в операционную систему и как происходит парсинг url в браузерах. Я пытался его остановить, но он всё же прочитал небольшую лекцию по модели OSI. И даже для наглядности обжал витую пару прямо во время собеседования. Ещё час он рассказывал про устройство DNS и детали работы WiFi сетей...

Собеседование закончилось 3 часа назад. А он продолжает писать нам на почту: про SSL/TLS Handshake, DOM, рендеринг, кеш, CSSOM, алгоритмы сжатия.
#найм

#game #meme про DOOM

#prog #article

Memory Unsafety is an Attitude Problem

<...>

That’s not to say memory safety isn’t important, it is. But lacking security is ultimately an attitude problem. If developers don’t care about it, forcing onto them a memory safe language will not accomplish anything. They’ll screw up some other way.

First make them care, then make it easy for them to do the right thing.

Впрочем, попенять статью можно за методику для подкрепления некоторых аргументов (комментарии на реддите? Серьёзно?)

— Я тебе кинул ссылку в запрещённой соцсети.
— В которой из?

Парашут було винайдено в 1783-му
Люди до 1783-го:

#prog #cpp

В стандартной библиотеке C++ есть unordered контейнеры, которые для проверки принадлежности элементов контейнеру используют хэш-функции (помимо равенства, разумеется). Для того, чтобы хэшировать значение, нужно знать, как это делается.

В C++ операции хеширования можно переопределять для конкретных контейнеров (это один из шаблонных параметров), но по умолчанию используется std::hash. Для того, чтобы определить операцию хеширования для своего типа, нужно написать специализацию std::hash для своего типа (обязательно в пространстве имён std) и написать свою реализацию operator(), которая будет принимать хэшируемый объект и возвращать std::size_t в качестве результата.

Пусть у нас вот такой простой тип:

struct Point {
    int x;
    int y;
};

Попробуем сделать его хешируемым:

#include <cstddef>
#include <functional>

template <> struct std::hash<Point> {
    std::size_t operator()(const Point& p) {
        // а как...
    }
};

И вот тут мы сталкиваемся с проблемой: при условии, что у нас все поля хэшируемые, как нам получить хэш от всех них? Увы, std тут вообще никак не помогает. Максимум, что могут предложить на просторах интернета — это использовать boost::hash_combine (это даже рекомендуют на cppreference.com). Мало того, что тащить буст ради этого не хочется, так ещё и комбинирование происходит на уровне готовых хэшей. Это фактически приводит к двойному хэшированию, что обычно на качестве хэш-функции сказывается не в лучшую сторону.

В теории можно было бы организовать разделение на саму хэш-функцию и на описание того, какие и в каком порядке поля типа хэшируются... То есть сделать так, как в Rust. И это даже предлагали сделать для C++ в предложении N3980 aka Types Don't Know #. И подано это предложение было... 24 мая 2014 года. То есть десять лет назад, да. А воз и ныне там.

Я написал очень длинный и очень интересный текст про Юникод. Поскольку в Telegram пост такого размера не помещается, выложил на сайт:

https://blo.gepar.do/v0/unicode.html

Все бегом читать :)

Однажды ты спросишь меня, что у меня на первом месте: ты или программирование. Я отвечу "программирование". И ты уйдёшь, так и не узнав, что я допустил ошибку на единицу и на первом месте — ты.

А программирование — на нулевом.

#лингво

Серия постов про изменение лексики в новостях России.

t.iss.one/anthro_fun/2882

#prog

GPU — вещь своеобразная, из-за отличной от CPU архитектуры преобразования кода имеют не самые очевидные последствия.

На странице Check if your performance intuition still works with CUDA перечислено несколько вопросов, каждый из которых демонстрирует два куска кода и предлагает угадать, насколько отличаются их производительность. Догадку потом можно проверить.

Учтите, изменения могут быть в обе стороны.

#prog #cpp

doctest is a new C++ testing framework but is by far the fastest both in compile times (by orders of magnitude) and runtime compared to other feature-rich alternatives. It brings the ability of compiled languages such as D / Rust / Nim to have tests written directly in the production code thanks to a fast, transparent and flexible test runner with a clean interface.

Советую также посмотреть, чем отличается от прочих фреймворков для тестирования в C++.