Блог* – Telegram
1.9K subscribers
3.46K photos
135 videos
15 files
3.69K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
#prog #cpp

Документ о EASTL — замене STL от Electronic Arts, вместе с описанием причин для её написания и отличиях от актуальных на тот момент (2007 год) реализациях STL.
Forwarded from вафля 🧇🍓
единственное для чего пригоден питон — умножать строки
Forwarded from мне не нравится реальность (waffle 🧇🍓)
NerdyPepper/eva

Простой REPL калькулятор с историей и подсветкой синтаксиса. На расте.
мне не нравится реальность
Зачем вести блог, если можно просто репостить Блог*?
Зачем вести Блог*, если можно просто репостить Вафлю?
Павел Дуров поделился 7 секретами вечной молодости:

1. Наличие однопараметрического типа Т
2. Наличие аппликативного функтора для типа Т
3. Наличие функции return
4. Наличие функций join или bind
5. Закон левой идентичности
6. Закон правой идентичности
7. Закон ассоциативности
xxx: Блин, вот мне нихрена не смешно — у меня начальник тоже двинутый по теме "сделать посложнее, чтобы никто не догадался".
xxx: Пока что догадаться не можем мы.

#prog #quotes
😁1
Ёлки-палки, я вроде бекендер, почему я сейчас гуглю по работе, можно ли использовать -- внутри тегов комментариев HTML?
Научно-фантастически-исторический роман "Ложная лепота"
Какое покрытие полезнее?
Anonymous Poll
20%
Кода тестами
80%
Антипригарное
🤔1
Беды с баш #rust-ом (#prog)
Forwarded from Vlad Beskrovnyi
Из-за отсутствия внятной спецификации, в расте то и дело возникают вопросы "'это баг или фича?". И когда все-таки решат, что баг, может выясниться, что он уже всеми повсюду используется, как фича. И вроде и людей в этом не обвинишь, ведь нигде не написано, что это баг - ведь ланг дезигнеры и сами внятно сказать не могли, баг или не баг! Приходится что-то выкостыливать. Вот напр я репортил - https://github.com/rust-lang/rust/issues/74556
Тут сначала не могли понять, баг или не баг. Потом все же решили, что баг. Потом выяснили, что он уже есть в нескольких стабильных релизах. Потом исправили, но выяснили, что кто-то баг уже использует, так что на новой найтли что-то перестало компилиться. Вроде решили, что и фиг с ним
Forwarded from гиг пиг ниг
#prog #computergraphics

Статья (перевод) о попытке сделать рендеринг поверх не чисел с плавающей точкой, а поверх рациональных чисел. Спойлер: для получения приемлемых результатов автору пришлось реализовать арифметику с "плавающей дробной чертой"
Forwarded from oleg_log (Oleg Kovalov)
Collection of articles on good practices and tools to improve C code quality

Интересно тем, что от автора LZ4 и ZSTD (можно сказать лучшие компрессоры данных, да, на Си)

https://github.com/Cyan4973/Writing_Safer_C_code
#prog #rust #моё

Рассмотрим следующий код на Rust:

// код опущен для краткости

fn main() {
let tricky = <Tricky as Default>::default();
assert_eq!(tricky.field, 7);
assert_eq!(tricky.field, 4);
assert_eq!(tricky.field, 13);

let mut nice_try = <NiceTry as Default>::default();
assert_eq!(nice_try.field, 0);
nice_try.field += 12;
assert_eq!(nice_try.field, 0);

let (mut a, mut b) = <(Unstable, Unstable) as Default>::default();
assert_eq!((a.field, b.field), (0, 0));
std::mem::swap(&mut a.field, &mut b.field);
assert_eq!((a.field, b.field), (10, 10));
}


Очевидно, этот код не работает. И действительно, если мы запустим эту программу, то один из ассертов запустит панику. В данном случае это будет... Будет... Погодите-ка, оно работает? Что?! Но ведь в Rust нет свойств!

Окей, признаю, я вас немного обдурил, вся фишка кроется в коде, который я не показал. Разумеется, я его покажу, а попутно затрону две темы в Rust: deref coercion и interiour mutability.

Но сначала давайте поговорим о слайсах. Они достаточно удобны. Их можно индексировать и снова получать слайсы. Для них определено множество полезных методов: сортировка, поворот, обращения порядка, линейный и бинарный поиски... Однако, все эти методы можно также вызвать и на массивах, и на Vec. Как это работает? Неужели реализация этих методов скопирована с методов для слайсов? Конечно, нет.

Давайте посмотрим на метод Vec::sort. Этот метод описан в блоке "Methods from Deref<Target = [T]>". Что это означает? В стандартной библиотеке Rust (на самом деле core) есть трейт Deref, описанный следующим образом:

trait Deref {
type Target: ?Sized;
fn deref(&self) -> &Self::Target;
}

Как нетрудно видеть, он позволяет получить из ссылки на значение одного типа ссылку на значение другого типа. У этого трейта есть дополняющий его DerefMut, который выполняет преобразование между мутабельными ссылками:

trait DerefMut: Deref {
fn deref_mut(&mut self) -> &mut Self::Target;
}

Возникает закономерный вопрос: а чем они отличается от AsRef и AsMut, которые также выполняют преобразования между ссылками? Ну, во-первых, в силу того, что целевой тип преобразования у Deref и DerefMut является ассоциированным типом, а не обобщённым параметром, у любого типа может быть не более одной реализации Deref и DerefMut. А во-вторых — и это уже куда как более существенное отличие — это один из "магических" (известных компилятору) трейтов, методы которого часто вызываются неявно. Конкретно методы Deref{, Mut} вызываются для кастомных реализаций операторов разыменовывания, а также ещё неявно в некоторых контекстах, в частности, при вызове методов через точку. Это, в том числе, позволяет эргономично пользоваться умными указателями. Если на минуту забыть о том, что Vec может менять свою длину, мы можем считать его ссылкой на лежащий в куче массив с длиной, известной лишь на этапе исполнения. То есть... Указатель на слайс. И действительно, Vec реализует Deref{, Mut}<Target = [T]>, что позволяет вызывать на нём методы, определённые для слайса. И при этом без каких-либо дополнительных телодвижений с вызывающей стороны!

Ладно, это было поучительно, но какое оно имеет отношение к безобразию, показанному в начале? Дело в том, что одна из (почему-то малоизвестных) ситуаций, когда методы этих трейтов могут вызваны — это... Доступ к полю. Если в коде есть foo.field и foo имеет тип Foo, у которого нету поля field, но Foo реализует Deref<Target = Bar>, где у типа Bar есть поле field, то такое обращение к полю будет корректно и будет вызывать deref (или deref_mut). Все те странные структуры, которые я показал, так или иначе оборачивают структуру Simple:

#[derive(Default)]
struct Simple {
field: u32,
}