Блог*

Если вашу (или чью-то ещё) задницу сравнивают с персиком — помните, что у персика на кожице волоски

#prog #cpp #article Fun with flat_map’s non-explicit constructors TL;DR: в коде ниже вызываются три разных конструктора flat_map:

void print_map(std::flat_map<int, int>);

print_map({ {1, 2, 3}, {10, 20, 30} });
print_map({ {1, 2}, {10, 20} });
print_map({ {1}, {10} });
print_map({ {}, {} })

#meme Это правда!

Pleeeease

#prog #моё #article В этот раз я написал слишком крупный для телеги пост — тут он занял бы семь постов. Поэтому держите ссылку на cold storage репозиторий для подобных текстов Блог*а: Почему свойства (property) в языках программирования — это плохая идея

#llvmweekly https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728 Зато много готовых оптимизаций из коробки. Так же автор (очень справедливо!) вопрошает, какого хрена в коде LLVM не используются арены и пулы, везде, налево, и направо, потому что основные причины тормозов LLVM - это деревянные структуры без data locality. У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%). Я систематически бенчил clang с разными аллокаторами, и остановился на tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти. Неутешительный вывод такой - начинать разработку компилятора стоит с LLVM, а вот дальше есть варианты.

#prog #article

#prog #cpp #article An informal comparison of the three major implementations of std::string (GCC, MSVC и clang) Все три варианта поддерживают SSO, но по разному этого достигают. (thanks @itpgchannel)

В блоге Фигмы (это гугл-документы от мира графического дизайна) вышла отличная статья (https://clck.ru/JsUmz) о том, как они делали многопользовательский редактор макетов. Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям. Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией. А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.

#prog #article Ни разу не пользовался Figma (не мой род деятельности), но читать про их технические детали, как правило, интересно.

А вот так волшебно цветёт персик в горной деревне на острове Сикоку в долине реки Ниёдо. Фотографы называют эту локацию «Шангри-ла», но непонятно, насколько это официально.

#science Нептун гораздо менее синий, чем многие считают. ras.ac.uk/news-and-press/news/new-images-reveal-what-neptune-and-uranus-really-look

Возможно, сегодня или завтра таки допишу и опубликую текст про property