#cpp
Simplify template code with fewer typename in C++20
https://www.cppstories.com/2022/less-typename-cpp20/

#poll
Спасибо за ваши ответы : ) Правильное решение было, но моё немного отличается, потому предлагаю такое:

template<class T, class... Args>
Node<T>* tree_get(Node<T>* top, Args... args) {
return (top ->* ... ->* args);
}

auto left = &Node<int>::left;
auto right = &Node<int>::right;

#cpp
[видео]: Declarative Control Flow.
Андрей Александреску(как всегда замечательный) рассказывает о std::uncaught_exceptions, SCOPE_EXIT, SCOPE_FAIL и SCOPE_SUCCESS.
https://www.youtube.com/watch?v=WjTrfoiB0MQ

#cpp #pub
Опубликовал ещё одну статью по аллокаторам. Спасибо @gepardius и @dranikpg за ревью и замечания.

#cpp #common
[видео]: Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step.
https://www.youtube.com/watch?v=ncHmEUmJZf4

#cpp #proposals
Ещё немножко предложений, принятых в С++23 (и не только).

1. Литерал z для преобразования чисел в size_t: wg21.link/p0330 .
2. any_invocable -- move-only std::function: wg21.link/p0288 .
3. #embed -- #include for binary data: wg21.link/p1967 .
4. |> -- новый неперегружаемый оператор для цепочки функций: wg21.link/p2011 .
5. Поддержка инструментов для работы с линейной алгеброй в библиотеке: wg21.link/p1385r0 .
6. std::colony или std::hive: wg21.link/p0447r4 .
7. allocate_with_size для аллокаторов: wg21.link/p0401r1 .
8. Postfix fold expressions: wg21.link/p2355r0 .
9. Argument type deduction for non-trailing parameter packs: wg21.link/p2347r2 .
10. Гарантированное copy elision для named return objects: wg21.link/p2025r0 .
11. Статическая рефлексия: wg21.link/p2320r0 .

#cpp
Краткий ликбез (наверное уже последний) по основным нововведениям в С++20.
cppstories.com/2022/20-smaller-cpp20-features/

#cpp
Рефлексия в C++Next на практике.
habr.com/ru/post/598981/

#cpp
Метапрограммирование в C++ и русская литература: через страдания к просветлению.
habr.com/ru/article/448466/

#cpp
[видео]
CppCon 2019. Timur Doumler. Type punning in modern C++.
Автор рассказывает об алиасинге типов и strict alias rule, выравнивании, неопределённом поведении и как его избежать.
youtube.com/watch?v=_qzMpk-22cc

#cpp
Динамический неоднородный плотно упакованный контейнер.
habr.com/ru/post/302372/

#cpp
Элементы функционального программирования в C++.

[из Википедии] Частичное применение - возможность в ряде языков программирования зафиксировать часть аргументов многоместной функции и создать другую функцию.
habr.com/ru/post/313370/

Композиции отображений.
habr.com/ru/post/328624/

#algo
Довольно приятный плейлист про не очень стандартные алгоритмы, которые ещё и хорошо поясняются.
www.youtube.com/playlist?list=PLc82OEDeni8SGp5CX8Ey1PdUcoi8Jh1Q_

#cpp #common
1. Некоторые способы определения битовых флагов.
m-peko.github.io/craft-cpp/posts/different-ways-to-define-binary-flags/

2. How to collapse nested switch statements.
www.fluentcpp.com/2017/06/27/how-to-collapse-nested-switch-statements/

3. How to choose good names.
www.fluentcpp.com/2017/01/30/how-to-choose-good-names/

4. A class without copy constructor.
quuxplusone.github.io/blog/2021/09/17/a-class-without-a-copy-constructor/

5. About (in)valid objects.
arne-mertz.de/2021/09/isvalid-establish-invariants-avoid-zombies/

#cpp
Помоги компилятору помочь тебе.
Автор рассказывает о флагах компиляции, что они делают, и почему стоит их использовать в своих проектах.
habr.com/ru/post/490850/

#cpp #proposals
Пачка новых предложений за январь.

1. У бумаги про std::hive уже 19 ревизий. И тут ещё появилась просьба вернуть это предложение в 23й стандарт. Оч интересно, как это предложение летает туда-сюда. Мне почему-то забавно.

2. Пары и туплы очень похожие типы, ведь первое просто частный случай второго. Туплы могут быть сконструированы из пар, но не наоборот. Такое положение наводит на мысли, что std::pair немного избыточен. Удалять его конечно никто не будет, но туплам можно добавить некоторые возможности пар, чтобы последние использовались реже. Proposal.

3. Из C делают современный язык, хех. Но местами выглядит это конечно мда: Basic lambdas for C, Improve type generic programming.

4. Ослабление ограничений для constexpr. На самом деле тут ничего капитального. Просто какие-то мелочи.

5. std::breakpoint для остановки при выполнении в дебаге. Честно говоря, не очень понимаю, зачем тащить это в язык. Дебагеры хорошо справляются.

6. std::is_debuger_present для понимания, отлаживается ли сейчас программа. Вот это уже что-то полезное. Довольно часто приходилось пихать вывод только для отладки.

7. Сделать move_iterator<T*> random_access итератором. Это поможет выполнять некоторые операции с ренджами эффективнее.

8. Более строгое требование для атрибута [[assume(...)]].

#common
The Little Things: Comparing Floating Point Numbers.
codingnest.com/the-little-things-comparing-floating-point-numbers/

#c #cpp

Попалась довольно сомнительная статья на хабре про редкие возможности в С. Учитывая половину списка, не очень понятно, что такое редкие возможности в понимании автора. Не предлагаю вам её читать, чтобы не тратить время. Остановлюсь только на самых интересных моментах и прокомментирую/добавлю немного информации.

1. Конкатенация строк времени компиляции.
Думаю, вы тоже видели какой-то подобный код:

std::string very_long_string = "This is first part of long string." "And this is second";

Никаких плюсов и функций конкатенации: компилятор сделает это одной строкой сам. Используя такое поведение можно реализовать интересный макрос:

#define LOG(exp) std::cout << "Result of " #exp "=" << exp;
int x = 12;
LOG(x*5);

Результатом будет "Result of x*5=60".

2. Препроцессорная склейка строк.
Как вы думаете, будет ли инкремент в следующем коде?

int inc(int x) {
// doing increment\
x++;
return x;
}

Вопрос в том, что произойдёт раньше: конкатенация строк, разбитых через \, или замена комментария на пробельные символы? Легко можно убедиться, что x++ станет частью комментария, то есть строки конкатенируются раньше. Я как-то смотрел замечательную лекцию по тулчейну, где пояснялся этот момент и думал "ну разве можно так набагать", а недавно мне рассказали, что обнаружили подобное в проде. Забавно.

3. Функции в стиле K&R.
Не знал, что такая возможность раньше была в C. Суть заключается в том, что вы объявляете функцию следующим образом:

int foo(s, f, b)
char* s;
float f;
struct Baz * b;
{
return 5;
}

в то время как сегодня она выглядела бы более привычно:

int foo(char* s, float f, struct Baz * b) {
return 5;
}

4. tmpfile.
В статье конечно речь идёт и сишной функции, однако есть аналог std::tmpfile (который тем не менее ничем не отличается). Автор не приводит каких-то полезных применений временных файлов. Мне когда-то было полезно при написании внешней сортировки (правда, там было использование std::tmpnam, но сути не меняет), а ещё, если внимательно посмотреть на то, что делает ваш компилятор при билде программы (например --verbose для g++), то можно увидеть, что компилятор создаёт некоторое кол-во временных файлов, которые можно даже попросить его не удалять.

5. Отрицательные индексы.
Делается такое довольно просто:

int* arr = new int[100] + 50;

Теперь можно обращаться по индексу в обе стороны. Только, как и всегда, стоит быть осторожным с границами и очищением памяти : )

6. std::new_handler.
В C++ есть такое понятие как new_handler (не новый обработчик, а обработчик оператора new). В случае, если new не может выделить необходимое количество памяти, он вызывает свой обработчик в надежде, что тот разрулит ситуацию: сделает дефрагментацию, что-то освободит, переназначит обработчик или что-нибудь ещё. В случае повторного неуспеха обработчик будет вызван ещё раз, то есть такая программа вполне приводит к бесконечной рекурсии:

void f() {}

int main() {
std::set_new_handler(f);
int* p = new int[1000000000000];
}

#highload

Попытаюсь с умным видом вкинуть инфы про высоконагруженность.

Очень важной задачей при разработке высоконагруженных систем является поддержание отказоустойчивости (часто хочется удержать что-то вроде 99.99% аптайма). У нас проверка работоспособности сервисов проверяется довольно понятно: проводятся учения по отключению одного из датацентров. Такие учения бывают внешние (для всей компании) и внутренние (для конкретных сервисов и продуктов). По своему (небогатому) опыту могу сказать, что такие мероприятия очень полезны: вроде на прошлой неделе всё прошло успешно, а сегодня уже проблемы с коннектами в базе, тайминги выросли или на сервисе начинает загораться congestion control.

Но рассказать хотелось бы об инструментах Netflix: chaos monkey.
Chaos monkey является частью chaos engineering (хотя можно сказать, что стала началом):

Chaos engineering is the discipline of experimenting on a distributed system in order to build confidence in the system's capability to withstand turbulent conditions in production.

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

Обычно падения настраиваются, чтобы отключение инстанса происходило в тот момент, когда команда наиболее готова к сражению с падением. "Падать" могут лишь те машинки, которые помечены для этого доступными. Все доступные для "уранивания" машинки делятся на группы. Каждый будний день обезьяна приходит в каждую группу инстансов и бросает монетку (если точнее, то монетка взвешеная), чтобы решить, ронять ли какую-то машинку из этой самой группы. Если она решает, что надо, то шчедулит падение на случайное время в промежутке от 9:00 до 15:00. Каждое приложение/сервис определяет 2 величины, на основе которых бросается монетка: среднее время в рабочих днях между падениями и минимальное время в рабочих днях между падениями.

Из минусов можно отметить:
- для chaos monkey необходимы spinnaker (система развёртывания в нетфликсе) и mysql;
- генерирует только псевдослучайные падения конкретного инстанса приложения/сервиса, в то время как разнообразие проблем в реальной жизни гораздо шире;
- работу chaos monkey нельзя просто так прервать. Если что-то пойдёт не так, остаётся только сражаться.

В какой-то момент одного инструмента стало не хватать, потому появилась simian army (которая, тем не менее, уже не поддерживается).

Simian army включает в себя ещё три основных инструмента:
1. Janitor monkey или сегодня swabbie -- аналог сборщика мусора для облачной экосистемы.
2. Conformity monkey проверял соответствие инстансов некоторым предефайненым правилам. В случае несоблюдения правил, инстанс отключался. Сейчас это часть spinnaker.
3. Security monkey проверял инстансы на различные дыры в безопасности.

и ещё несколько, которые были депрекейтнуты сильно раньше или не опубликованы:
4. Chaos gorilla, который симулировал отключение одной из 25 зон инфраструктуры AWS (т.е. отключение огромной части всех инстансов).
5. Chaos kong -- аналог прошлого инструмента, но симулирующий отключение меньших частей инфраструктуры.
6. Latency monkey -- тулза, увеличивающая тайминги ответов некоторых ручек в сервисах.
7. Doctor monkey -- инструмент, мониторящий состояние инстансов. Если инстанс "заболел" (пятисотит, выросли тайминги или кушает много cpu), doctor убирает его из приложения.
8. 10-18 monkey (i.e. l10n-i18n) проверяет работу сервисов, которые работают в различных географических зонах. Чекаются проблемы связанные с локализацией и всем что около.

Массивная и интересная (мне показалось) статья про fork().
https://habr.com/ru/post/586604/

#common

Аллокатор как метод управления памятью впервые появился в С (речь не о std::allocator, а о самом термине, который был реализован в malloc/free), а своё, можно сказать, известное воплощение получил в C++ как std::allocator (в 1994м) и std::pmr::allocator (В C++17). Однако не одними C/C++ едины. Аллокаторы также существуют и в других языках программирования (как самостоятельный термин, так и наследие/заимствование C/C++).

В силу развития языка в какой-то момент аналоги malloc/free появились в COBOL и Fortran 90. Аналогичный метод управления памятью есть и в D (malloc, new), т.к. он появлялся как более правильный C++ и тянет за собой часть стандартных библиотек C/C++, хотя сам D имеет свой сборщик мусора.

Но эти примеры немного надуманы, потому что термин аллокатор тут появляется из аналогичности методов управления памятью.
Более честными примерами являются:

1. Rust.
Из интересного можно отметить две вещи.
В расте есть глобальный аллокатор, который в отличие от C/C++
очень легко подменить:

#[global_allocator]
static GLOBAL: MyAllocator = MyAllocator;

До версии 1.28 rustc неявно линковал jemalloc в каждую свою программу. Чтобы ослабить зависимость от libc, это поведение изменили в сторону стандартного системного аллокатора.

update: В C++ тоже можно "подменить" глобальный аллокатор.
Перегрузим глобальные операторы new/delete, засунув в них соответствующие операции из готового аллокатора. Единственное что это всё-таки немного неполноценно в силу того, что используемый аллокатор может работать только с памятью (ведь вызов конструктора/деструктора не переопределяется), а интерфейс std::allocator до C++20 (пусть он и не прав идеологически, что такими вещами занимается) всё-таки хочет и это контролировать. С 20ого стандарта методы construct/destroy удаляются и заменяются на std::construct_at/std::destroy_at. В таком виде можно говорить о корректной замене глобального аллокатора.

2. Zig.
Тут нет дефолтного аллокатора. Чаще всего вы выбираете свой аллокатор согласно рекомендациям и отдаёте его как параметр. Если вы пишете свою библиотеку, авторы предлагают придерживаться подобной концепции и требовать у пользователя аллокатор, который ему нравится. А вообще он предоставляет (не сказал бы что богатый, но) зоопарк из нескольких аллокаторов, которые вам могут понадобиться: от std.heap.c_allocator (C malloc/free) и нескольких пул-аллокаторов до аллокаторов для тестирования и std.heap.GeneralPurposeAllocator, если вам ничего не подошло (так написал, будто между крайними случаями ещё солидное кол-во аллокаторов, хотя на самом деле я перечислил почти все).