fa
Feedback
Блог*

Блог*

رفتن به کانال در Telegram

Блог со звёздочкой. Много репостов, немножко программирования. Небольшое прикольное комьюнити: @decltype_chat_ptr_t Автор: @insert_reference_here

نمایش بیشتر
1 923
مشترکین
اطلاعاتی وجود ندارد24 ساعت
-47 روز
-830 روز
آرشیو پست ها
photo content

Ну, #meme про людей в IT

http://cpu.land — ресурс, рассказывающий о том, как именно происходит запуск программ в компьютере. К сожалению, практически всё, что касается OS — Linux-специфично. Но даже так всё равно познавательно

#prog Frangipanni — program to convert lines of text into beautiful tree structures. Пример. Вход:
/etc/bluetooth/rfcomm.conf.dpkg-remove
/etc/bluetooth/serial.conf.dpkg-remove
/etc/bluetooth/input.conf
/etc/bluetooth/audio.conf.dpkg-remove
/etc/bluetooth/network.conf
/etc/bluetooth/main.conf
/etc/fish
/etc/fish/completions
/etc/fish/completions/task.fish
 
Вывод:
etc
    bluetooth
        rfcomm.conf.dpkg-remove
        serial.conf.dpkg-remove
        input.conf
        audio.conf.dpkg-remove
        network.conf
        main.conf
    fish/completions/task.fish
Можно также выводить в JSON и вручную задавать разделители. Попенять можно разве что за длинные ключи с одиночными дефисами вместо удвоенных (т. е. ключи как в find, например).

Пишу заметки о релизе @ Хочу написать пример с #[expect] @ Нахожу баг

▪️Кстати, насчёт паник: вывод паник (по крайней мере, с panic hook по умолчанию) теперь предотвращает перемешивание вывода, если паникуют несколько потоков одновременно. ▪️Ещё касательно паник: PanicInfo разделили на два типа. Первый, в core, используется как аргумент в #[panic_handler] (вне #![no_std] не актуально), а второй, в std (переименованный в PanicHookInfo) как аргумент для хука паники. Как пишет Мара Бос: PanicInfo is used in two ways: As argument to the #[panic_handler] in no_std context. As argument to the panic hook in std context. In situation 1, the PanicInfo always has a message (of type fmt::Arguments), but never a payload (of type &dyn Any). In situation 2, the PanicInfo always has a payload (which is often a String), but not always a message. ... I don't see any good reasons for these to be the same type, other than historical reasons. Как следствие, std::panic::PanicInfo теперь является алиасом (с #[deprecated]) на PanicHookInfo. ▪️И ещё насчёт паник: PanicInfo (который в core) обзавёлся новым методом message, который возвращает новый тип PanicMessage, реализующий Display. Да, сейчас это тонкая обёртка над fmt::Arguments. ▪️Стабилизировали новые API, в том числе: 🔸 core::error. Да, само по себе это не новое API, но трейт Error теперь можно использовать в #![no_std] 🔸hint::assert_unchecked — вызывает UB, если аргумент является false. Может быть полезно для того, чтобы сообщать оптимизатору инварианты, которые компилятор сам не выводит. 🔸fs::exists — фактически алиас для Path::try_exists, не переводит ошибки в false. 🔸AtomicBool::fetch_not 🔸Duration::abs_diff В const-контексте теперь можно вызывать: 🔸char::from_u32_unchecked (и метод, и функцию в core::char) 🔸CStr::{count_bytes, from_ptr}

#prog #rust #rustreleasenotes Вышла версия Rust 1.81.0! Как всегда, котлеты детальные заметки о релизе отдельно, а мухи мои хайлайты отдельно. ▪️Компилятор теперь несколько иначе выводит лайфтаймы. Раньше при наличии self компилятор выводил время жизни из ссылки на Self, если оно было. Теперь компилятор ищет ссылку не непосредственно на Self, а на тип, включающий в себя Self, и прерывает компиляцию, если в типе self больше одного лайфтайма. Примеры из PR:
// ранее компилировалось, а теперь нет
fn a(self: &Box<&Self>) -> &u32
fn b(self: &Pin<&mut Self>) -> &String
fn c(self: &mut &Self) -> Option<&Self>
fn d(self: &mut &Box<Self>, arg: &usize) -> &usize

// ранее не компилировалось, теперь компилируется
fn f(self: &Box<Self>) -> &u32

// компилируется, но теперь выбирает иной лайфтайм
fn e(self: &mut Box<Self>, arg: &usize) -> &usize
//         ^ теперь             ^ раньше
▪️Ещё насчёт лайфтаймов: компилятор теперь по умолчанию не компилирует код с ассоциированными константами с лайфтаймами в типах, если есть именованные лайфтаймы в текущей области видимости:
struct Foo<T>(T);

impl<'a> Foo<&'a ()> {
    const STR: &str = "hello, world"; // низзя (но можно #[allow], если хочется)
}

impl Foo<()> {
    const STR: &str = "hello, world"; // можно, других лт нет, выводится 'static
}
▪️Стабилизировали атрибут #[expect], который заставляет компилятор выдавать предупреждение, если указанный линт не срабатывает. Пример:
fn consume(_: i32) {
    todo!()
}

pub fn foo() {
    let mut x = 0; // warning: variable does not need to be mutable
    consume(x);
}

pub fn bar() {
    #[expect(unused_mut)]
    let mut x = 0; // нет предупреждений
    consume(x);
}
Эта вещь особенно полезна при написании чернового варианта кода. В отличие от #[allow], компилятор будет выдавать предупреждение, когда весь код, вызывающий срабатывание указанного линта, будет исправлен. ▪️Ещё изменение касательно атрибутов для линтов: если подобный линт вызывает предупреждение компилятора, то оно теперь непосредственно включает сообщение из reason:
fn consume(_: i32) {}

#[deny(unused_mut, reason = "mutability is evil")]
pub fn f() {
    let mut x = 0;
    consume(x);
}
Вывод:
error: variable does not need to be mutable
 --> src/lib.rs:5:9
  |
5 |     let mut x = 0;
  |         ----^
  |         |
  |         help: remove this `mut`
  |
  = note: mutability is evil
note: the lint level is defined here
 --> src/lib.rs:3:8
  |
3 | #[deny(unused_mut, reason = "mutability is evil")]
Строка = note: mutability is evil ранее отсутствовала в выводе. ▪️У большинства вариантов ABI в Rust есть *-unwind варианты, которые позволяют паникам пересекать границу FFI. Для вариантов ABI без *-unwind такое поведение является UB. В этой версии Rust программа теперь прекращает работу (abort), когда паника пересекает границу ABI, не поддерживающего раскрутку стека. ▪️offset_from теперь можно всегда применять на указателях с одинаковыми адресами, вне зависимости от их происхождения (provenance). Да, в том числе на указателях из разных аллокаций. Сделано это для достижения provenance monotonicity: добавления произвольного provenance указателям не может добавить UB в программу, в которой UB не было. ▪️{Rc,Arc}::make_mut() теперь работают на слайсах из клонируемых значений. Реализовано через отдельный нестабильный трейт, так что для своих типов реализовать не получится, увы. ▪️До стейбла дошли улучшения сортировок. Да, теперь ваш говнокод в реализации Ord может вызвать панику.

#ai #хуи
#ai #хуи

#meme про XML

#prog #rust #article Defeating Coherence in Rust with Tacit Trait Parameters TL;DR: чтобы можно было иметь "две различные" реализации трейта для типа, можно добавить в трейт ти́повый параметр, нужный исключительно для придания различия, а чтобы это было эргономичным — сделать тип таким, чтобы его можно было вывести по месту применения. Для функций в качестве такого типа прекрасно работает кортеж аргументов.

#prog #article Store Code Discussions in Git using Git Notes Эргономика, правда, так себе. (thanks @rustlang_by)

Repost from Neural Machine
Банан?

#prog #rust Changes to impl Trait in Rust 2024 Starting in Rust 2024, we are changing the rules for when a generic parameter can be used in the hidden type of a return-position impl Trait: a new default that the hidden types for a return-position impl Trait can use any generic parameter in scope, instead of only types (applicable only in Rust 2024); a syntax to declare explicitly what types may be used (usable in any edition). The new explicit syntax is called a "use bound": impl Trait + use<'x, T>, for example, would indicate that the hidden type is allowed to use 'x and T (but not any other generic parameters in scope).

photo content

#cpp #article #performancetrap Производительность неупорядоченных контейнеров зависит, понятное дело, от структуры данных, используемой для реализации. Однако требования к API могут существенно ограничить возможные варианты реализации и, соответственно, потенциал для производительности. Пожалуй, наиболее показательный пример применительно к C++ — это std::unordered_map. В отличие от std::map, к этому контейнеру нет требования, что элементы должны храниться в отсортированном порядке. По идее, это должно развязывать руки тем, кто пишет контейнеры. Однако стандарт C++ также накладывает серьёзные ограничения на стабильность итераторов для unordered_map. Именно, стандарт предписывает, что операции мапы инвалидируют ссылки на ключи и элементы только в том случае, если элементы удаляют — все остальные операции, включая всё то, что вызывает пересчёт хешей, ссылки сохраняют. На практике это означает, что любая конформная реализация обязана класть хранимые элементы в отдельный узел — с указателями на следующий и предыдущий элемент — память под который выделяется в куче. Мало того, что это требует +2 * sizeof(ptr) на каждый элемент — из-за использования аллокатора память под элементы выделяется в относительно произвольном порядке, что не позволяет нормально задействовать кеш процессора. Альтернативные реализации, такие, как abseil::flat_hash_map, могут иметь на порядок более высокую производительность за счёт использования структур данных, лучше использующих кеш процессора — ценой гарантий стабильности итераторов, разумеется. Но есть и более тонкие ловушки. У std::multiset — упорядоченного контейнера, поддерживающего более чем однократное вхождение элементов — есть методы lower_bound, upper_bound и equal_range. Первые два метода возвращают первое и последнее вхождение указанного элемента в упорядоченной последовательности, а третий возвращает два итератора, между которыми находятся все элементы, равные предоставленному. В C++11 был добавлен неупорядоченный аналог этого контейнера — std::unordered_multiset. lower_bound и upper_bound по понятным причинам не имеют смысла для этого контейнера, а вот equal_range есть — видимо, для облегчения миграции с std::multiset. Но есть небольшая проблема: этот метод возвращает пару обычных итераторов. А это подразумевает, что все равные элементы хранятся в контейнере подряд. Соответственно, insert должен делать дополнительную работу по поиску места для вставки, и становится всё медленнее по мере увеличения числа элементов. В статье unordered_multiset’s API affects its big-O автор модифицировал реализацию unordered_multiset из libc++, убрав метод equal_range. Замеры показали, что это позволяет изменить код, чтобы существенно ускорить метод insert.

Repost from /g/'s Tech Memes
uBlock filter to filter AI slop from search engines: https://github.com/laylavish/uBlockOrigin-HUGE-AI-Blocklist

photo content

#prog #article Everyone quotes command line arguments the wrong way ...По крайней мере, на Windows