#prog #cpp #rust #article

Why we didn't rewrite our feed handler in Rust

Отдельно отмечается, что Rust в технологическом стеке в этой компании уже есть и успешно используется. Проблемы возникли с переписыванием конкретного компонента, который уже есть и написан на C++. Конкретно в тексте приведены три паттерна, которые валидны в C++ и не выразимы или выразимы неудобно на Rust.

Первое касается ограничений borrow checker-а. Вот какой пример приводят:

fn process_source(sources: Vec<Source>) {
    for source in sources {
        let mut buffer: Vec<&[u8]> = Vec::new();
        let data: Vec<u8> = source.fetch_data();
        buffer.extend(data.split(splitter));
        process_data(&buffer);
    }
}

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

error[E0597]: `data` does not live long enough
  --> src/lib.rs:32:23
   |
31 |         let data: Vec<u8> = source.fetch_data();
   |             ---- binding `data` declared here
32 |         buffer.extend(data.split(splitter));
   |         ------        ^^^^ borrowed value does not live long enough
   |         |
   |         borrow later used here
33 |         process_data(&buffer);
34 |     }
   |     - `data` dropped here while still borrowed

Второй паттерн — самоссылающиеся структуры, известная больная тема в Rust.

Третий паттерн — множество определений разных версий и унифицированный код для работы с ними (из-за необходимости поддержки разных версий схем обмена данных, насколько я понял). Пример из статьи на C++:

struct RecV1 {
    uint32_t x;
    uint32_t y;
}

struct RecV2 {
    uint32_t x;
    uint32_t y;
    uint32_t z;
}

Унифицированный код для работы с обоими этими типами можно написать при помощи шаблонов:

template <typename T>
T InitRec() {
    T res;
    res.x = 1;
    res.y = 2;
    if constexpr(std::is_same_v<T, RecV2>()) {
        res.z = 3;
    }
    return res;
}

Нетрудно видеть, как это обобщается на случай большего количества полей и различных версий. В Rust можно попробовать сделать нечто подобное, но это вырождается в бойлерплейт, облегчать который приходится макросами — иными словами, попытка повторить шаблоны из C++.

#prog #cpp #suckassstory

Source

BTW это было в Rust std с самой первой версии, то есть с середины 2015 года. В #cpp подобная вещь называется heterogeneous lookup, и хотя она реализована для контейнеров в std, она opt-in. Для упорядоченных контейнеров нужно явно дописывать std::less<> в шаблонные параметры типа, а для неупорядоченных вообще надо самостоятельно писать хешер и явно дописывать is_transparent в определении. Вдобавок heterogeneous lookup на упорядоченных контейнерах был с C++14, а вот на неупорядоченных его не было до выхода C++20 — то есть на четыре года позже, чем в Rust.

#prog #cpp #article

On push_back_unchecked: Performance with FromIterator and Collect

TL;DR: в другом посте предлагали добавить в вектор операцию push_back_unchecked, которая не проверяет ёмкость перед записью (и, соответственно, на полном векторе даёт UB). Замеры показали, что это даёт ускорение по сравнению с push_back в цикле. Автор же этой статьи сделал API FromIterator (взятый из std Rust) для своей библиотеки контейнеров и показал, что для таких юзкейсов можно добиться сопоставимого ускорения по сравнению с std::vector без возможности вляпаться в UB.

#prog #ml #cpp #article

Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом

(от Андрея Карпова, который глава PVS-Studio)

#prog #ml #cpp #meme

Source

#prog #rust #cpp #article

How (and why) we rewrote our production C++ frontend infrastructure in Rust

"Фронтенд" в данном случае означает прокси-сервер, если что.

“Should we convert our _ code to Rust?” is a question that comes up a lot. And a lot of the time the right answer is a pretty firm, “No.” So I thought it might be beneficial (and hopefully interesting) to walk through a case where the code involved was incredibly you-cannot-fuck-this-up business-critical and when we asked that question about it, we came back with a yes. Here’s what it was, how we got to that answer, and what we did about it.

The bottom line is that C++ has caused more than a few situations where we wanted to do something or add a feature and it’s just like… that’s a cool idea, but it’s just not worth the uphill battle against the language. And it was to the point where any change carries the risk of unforeseen consequences.