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

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

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

Что вы думаете о том, как я пишу? Что есть хорошего, а что стоит поменять? Хочу отметить, что я спрашиваю именно о слоге, а не о тематике.

Вчера я провёл стрим, где начал писать двухсторонюю хэшмапу. Т.е. если в обычной HashMap отношение K -> V, то в BiHashMap отношение K <-> K'.
‍
Всё пошло не так, как бы хотелось (я это ожидал и поэтому не публиковал тут ссылку на стрим), но в итоге я смог написать BiHashMap с парой самых базовых методов вроде insert и lget.

Вот тут можно посмотреть запись с вырезанными попытками починить стрим.

Я вроде смог настроить obs так, чтобы стрим больше не лагал, так что завтра продолжу писать BiHashMap, там ещё много чего надо сделать:
— Перейти с StaticRc на что-то другое (на стриме объясню почему)
— Дописать остальные методы, только с new, insert и lget в этом всём нет смысла
— Написать итераторы
— etc

Завтра, вс, 2022-02-13, ~16:00 @ twitch.tv/wafflelapkin

Блин, нахрена я решил решать задачи с Leetcode на C++. Очень больно из-за тупо отсутствующих возможностей и стандартной библиотеки версии C++17. span-ов нету, range-ей нету. И кто, блин, вообще придумал, что pop_{front, back} возвращает void вместо T, да ещё и с UB на пустом контейнере?

Через десять минут

remove_убешки



#[deny(PartialEq)]

"Это так раздражает, что insert ничего не меняет"

"Нам просто нужен entry API"

"Формат убил мои комментарии"

#wafflecontext

Так, стрим прекратился, так что шитпост окончен

TL;DR того, что случилось за 3 часа стрима:
— Кратко рассказал о том, что было на предыдущем стриме
— Написал небольшой типчик Mrc<_>, который по сути немного-более-безопасный указатель
— Переписал крейт с использования StaticRc, на Mrc
— Попытался написать {l,r}get_mut, понял что для BiHashMap такие методы не имеют смысла, разочаровался в жизни и впал в уныние
— Написал метод lreplace
— Неудачно попытался добавить проверки корнер кейсов в insert
— Долго пытался исправить проверки и избавиться от UB
— Придумал как правильно и просто написать проверки корнер кейсов в insert (оказалось почти совсем просто)

Итоговая реализация insert греет мне душу :)

#prog #python #rust #article

Статья про оптимизацию одной симуляции. Несмотря на (очевидное) переписывание на расте, автор смог добиться четырёхкратного ускорения исключительно за счёт правок в коде на питоне.

#prog #rust #rustlib

document-features — макрос для генерирования документации по фичам крейта. Фактически реализует док-комментарии для фич в Cargo.toml:

[dependencies]
document-features = "0.1"
## ...

[features]
## The foo feature enables the `foo` functions
foo = []
## The bar feature enables the [`bar`] module
bar = []

#! ### Experimental features
#! The following features are experimental

## Activate the fusion reactor
fusion = []

...И всё это в итоге преобразовывается макросом document_features::document_features! в строку, которую можно вставить в #[doc]

Ну и почему оно не компилируется?

#prog #rust #meme

using map = std::unordered_map<std::remove_reference_t<decltype(nums)>::value_type, int>;

Не давайте растистам (мне) писать код на C++.

#prog

Данила рассказывает, когда read-write lock может быть хуже обычного mutex в, казалось, идеально подходящем под read-write lock сценарии, и что с этим делать

#prog #rust

Вафель рассказывает про макрос pin!, добавленный в std совсем недавно, и про то, чем он отличается от аналогичных макросов из tokio и futures

cursed-fact-of-the-day: бинарный поиск по массиву из 2^20 элементов примерно на 20% медленнее, чем бинарный поиск по массиву из 2^20 + 123 элементов.

Причина: https://en.algorithmica.org/hpc/cpu-cache/associativity/

Источник: twitter@sergey_slotin