Что нужно делать при начале разработки тулзы по работе? Правильно, искать подходящее название в греческой мифологии.

#prog #rust #article

Статья об использовании PGO для rustc. В двух словах: улучшения есть, и весьма заметные, но пока что непонятно, как это можно интегрировать с CI

Тем временем @ihatereality делает что-то странное с @optozorax_dev. Что это? Может, он так заигрывает? 🤔

#prog #rust #моё

Как сравнить в Rust две строки, игнорируя регистр символов? Строго говоря, используя лишь стандартную библиотеку — никак, поскольку перевод из одного регистра в другой зависит от локали, но давайте пока проигнорируем эту деталь и притворимся, что среди пользователей нашего приложения нет кого-то, кто живёт в Турции или Азербайджане (а также что у нас нет проблемы нормализования строк).

Итак, как же нам сравнить две строки, игнорируя регистр символов? Большинство Rust-программистов (особенно новичков) напишут что-то вроде этого:

fn equal_ignoring_case(a: &str, b: &str) -> bool {
    a.to_lowercase() == b.to_lowercase()
}

Правильное ли это решение? НЕТ, НЕПРАВИЛЬНОЕ, КТО ВООБЩЕ ТАК ПИШЕТ Технически оно верное, но оно делает много лишней работы. Что тут происходит? Сначала под первую строку выделяется место в куче, которое заполняется проходом по строке с преобразованиями по довольно нетривиальным правилам, во время которых выполняется бинарный поиск по захардкоженным таблицам, затем то же самое происходит для второй строки, и только после этого строки сравниваются друг с другом. Всё это происходит даже в том случае, если строки большие и даже если строки различаются уже первым символом.

Можно ли сделать лучше? Разумеется: мы можем преобразовывать символы в нижний регистр не сразу все, а на лету, по требованию. Используя стандартную библиотеку, легко написать подобную функцию, которая ещё и не выделяет память в куче:

fn equal_ignoring_case(a: &str, b: &str) -> bool {
    a.chars().flat_map(char::to_lowercase).eq(b.chars().flat_map(char::to_lowercase))
}

(тут используется почему-то малоизвестный метод Iterator::eq, который проверяет, что два итератора выдают равные последовательности элементов)

А что делать, если одна из строк заведомо содержит лишь ASCII символы (например, это литерал для какого-нибудь формата разметки)? В таком случае мы можем игнорировать юникодные правила преобразования и проверять лишь равенство ASCII-символов без учёта регистра, что значительно более простая задача. Мы можем эксплуатировать тот факт, что строка — это набор байт, проверять строки побайтово, перед этим ещё и проверить, что у них одинаковая длина... Или же не переизобретать велосипед и воспользоваться готовым методом str::eq_ignore_ascii_case.

Немного усложним задачу: теперь нужно определить, что одна строка начинается с другой, игнорируя регистр. Решение в лоб:

fn starts_with_ignoring_case(s: &str, prefix: &str) -> bool {
    s.to_lowercase().starts_with(&prefix.to_lowercase())
}

, но оно не оптимально по тем же причинам. К сожалению, трюк с Iterator::eq здесь не подойдёт, потому что этот метод может вернуть true в том случае, если s короче prefix и потому не может его содержать. По аналогичным причинам не подойдёт Iterator::zip. К сожалению, придется написать немного кода самому, с ручными вызовами next:

fn starts_with_ignoring_case(s: &str, prefix: &str) -> bool {
let mut s = s.chars().flat_map(char::to_lowercase);
let mut prefix = prefix.chars().flat_map(char::to_lowercase);
while let Some(s_ch) = s.next() {
match prefix.next() {
Some(p_ch) => if s_ch != p_ch {
return false
},
None => return true, //префикс закончился, а все символы до это совпадали
//значит, строка содержит префикс
}
}
//закончились символы в строке, и они все совпали с символами в префиксе
true
}

Разумеется, и тут применима оптимизация, если одна из строк состоит только из ASCII-символов:

fn starts_with_ignoring_ascii_case(s: &str, prefix: &str) -> bool {
s.get(..prefix.len()).map_or(false, |start| start.eq_ignore_ascii_case(prefix))
}

Почему я решил об этом написать? Да потому что меня бесит, когда я вижу подобный настолько неоптимальный код. Так что можете считать, что это #бомбёжкипост.

#prog #rust #performancetrap #article

Статья о том, как апгрейд до новой версии tokio привёл к тому, что сервер, обычно отвечающий меньше, чем за миллисекунду, начал отвечать ровно за 40 миллисекунд. Спойлер: как всегда в подобных случаях, баг образовался из-за взаимодействия нескольких механизмов, включая части из linux.

Я говорил это ранее и скажу ещё раз: Вафель умница. Вскоре после того, как я выложил этот пост, он опубликовал вариант starts_with_ignoring_case с более простой реализацией.

#prog #rust #rustlib

Библиотека spirit — для снижения количества бойлерплейта при написании долгоживущих серверов. Логгирование, перечитывание конфигов при изменении, реагирование на сигналы, оборачивание в демоны — вот это вот всё.

#prog #rust #rustlib #amazingopensource

Заметки о библиотеке для использования постфиксных макросов, с изложением мотивации для её создания, истории вопроса и немного о реализации.

use postfix_macros::{postfix_macros, unwrap_or};

fn main() {
    postfix_macros! {
        let urls = ["https://rust-lang.org", "https://github.com"];
        for url in urls.iter() {
            let mut url_splitter = url.splitn(2, ':');
            let scheme = url_splitter.next().unwrap();
            let _remainder = url_splitter.next().unwrap_or! {
                println!("Ignoring URL: No scheme found");
                continue;
            };
            println!("scheme is {}", scheme);
        }
    }
}

Мои знакомые — особенно те, кто сами ведут свой канал в Телеграм — спрашивают, как мне удаётся постить качественный контент каждый день.

Ответ очень прост: я выкладываю некачественный контент.

#psy

О том, как правильно извиняться. Написано в контексте брака, но, на мой взгляд, вполне применимо и в более общих ситуациях.
TL;DR: Извиняетесь, но не заставляйте просить прощения

В этот раз ссылка на приватный канал в Telegram, так что вот вам сначала инвайт, а потом уже и ссылка на сам пост.

блять, опять я всё своё свободное время потратил в телегу и нихера не напрогал. Надо удалять её нафиг

#prog #cpp

twitter.com/AffectiveCpp — лучший твиттер-аккаунт о C++. Полезен даже профессионалам, а новичкам так и вовсе практически обязателен.

#prog #cpp

Действительно, выразительный.

https://twitter.com/Nekrolm/status/1326175405397651457

#prog #rust #compiler #article

Восхитительная длинная статья от Крендель-молота про написание компилятора brainfuck под x86_64, ARM64, WASM и LLVM IR.

github.com/pretzelhammer/rust-blog/blob/master/posts/too-many-brainfuck-compilers.md

#prog #rust tip: спецификатор фрагмента vis в макросах сопоставляется с описанием видимости определения, в том числе и пустым.

К примеру, следующий код компилируется:

macro_rules! accept_with_vis {
    ($vis:vis struct $name:ident;) => {}
}

accept_with_vis!{struct Foo;}

...Но не когда нужно сопоставиться только с спецификатором видимости (thanks @sajitar, который и заполнил issue). Вот этот код не компилируется:

macro_rules! accept_just_vis {
    ($vis:vis) => {}
}

accept_just_vis!{}

#prog #rust #моё

Как многие из вас знают (а если не знаете — узнаете сейчас), в Rust нельзя перемещать (move) поля из значения типа, имеющего нетривиальную реализацию Drop. В частности, значение типа, реализующего Drop, нельзя деструктурировать. Однако надо отметить, что если тип поля реализует Copy, то к этому полю можно обратиться, в том числе и пре деструктуризации, при этом значение этого поля скопируется. Проиллюстрирую только что сказанное:

struct NonCopy;

struct Dropping<T>(T, NonCopy);

impl<T> Drop for Dropping<T> {
fn drop(&mut self) {
println!("dropped");
}
}

fn main() {
// ⬇️ если раскомментировать эту строку, то программа не скомпилируется с E0509
// let Dropping(_non_copy, _) = Dropping(NonCopy, NonCopy);

// А вот это — компилируется и печатает "dropped".
// Обратите внимание, паттерн `_` *не* перемещает значение.
let Dropping(_x, _) = Dropping(0_u32, NonCopy);
}

Где это может выстрелить? При написании биндингов к сишным либам. Одна их техник обеспечения инкапсуляции в C — это определение структуры в заголовочном файле без определения её полей. Это позволяет получить доступ к полям структуры только там, где дано её определение, а внешний код может обращаться к ней лишь по указателю. И указатель — это Copy-тип, да.

Пусть это выглядит примерно так:

extern "C" {
// extern types ещё не стабилизированы, так что
// в реальной библиотеке, скорее всего, будут использовать *mut std::ffi::c_void


    type Some_C_Struct;
    fn c_lib_release_resources(arg: *mut Some_C_Struct);
}

struct Handle(*mut Some_C_Struct);

impl Drop for Handle {
    fn drop(&mut self) {
        unsafe { c_lib_release_resources(self.0) }
    }
}

Что произойдёт, если мы попытаемся деструктурировать Handle? Скажем, нам зачем-то потребовалась реализация метода leak:

impl Handle {
    fn leak(self) -> *mut Some_C_Struct {
        // Здесь мы разбираем значение, но так как указатель — Copy-тип,
        // имя ptr привязывается к копии значения, перемещения не происходит.
        let Handle(ptr) = self; // <-- после этой точки с запятой кончается время жизни self, и вызывается деструктор
        // Ура, у нас на руках невалидный указатель!
        ptr
    }
}

Что можно с этим сделать? Использовать ManuallyDrop. Этот тип предотвращает вызов деструктора (а также деструктуризацию, поскольку у него приватные поля), но при этом не предотвращает доступ к полям значения внутри (через Deref). Возникает вопрос, почему не использовать std::mem::forget? В принципе, в документации подробно расписано, но если коротко, то std::mem::forget значительно сложнее корректно использовать.

Сишный код в двух словах:

Бе ды
с
вла дением

Прошу прощения, в предыдущем опросе один диапазон возрастов просто не был представлен