#cpp

В стандартной библиотеке иногда встречаются функции, которые не выглядят однозначно. Один из таких примеров: std::exchange:

template< class T, class U = T >
T exchange( T& obj, U&& new_value );

Что делает функция?

Она присваивает obj new_value, и возвращает старое значение obj. Т.е. код ниже эквивалентен:

auto var = std::exchange(a, b);

auto var = a;
a = b;

(я конечно опустил детали move/forward, потому что сейчас важна концепция)

Зачем эта функция нужна? Явно не для сокращения кода на строчку каждый раз, когда у вас возникает подобная ситуация. В стандартную библиотеку ради такого вряд ли бы добавили что-то. Скорее ради упрощения какой-то частой операции. Или для выражения какой-то конкретной семантики.

Вот тут как раз второй случай. Примеры:
• хотим сбросить флаг, при этом прочитав старое значение:

if (std::exchange(shutdown_requested_, false)) {
    shutdown();
}

• передача владения в move-кторе:

Widget(Widget&& other)
    : handle_(std::exchange(other.handle_, nullptr)) {}

• извлечение текущего состояние (с переходом в следующее):

auto old_state = std::exchange(state_, State::Running);
process(old_state);

• получить значение optional и очистить его:

auto value = std::exchange(pending_value_, std::nullopt);

Плохие примеры:
• присваивание:

std::exchange(enabled_, true);

enabled_ = true;

• старое значение можно выразить очевиднее:

auto old = std::exchange(counter_, counter_ + 1);

auto old = counter_++;

• когда содержит сложное вычисление:

auto old = std::exchange(
    state_,
    compute_next_state(state_, request, dependencies));

Тут надо разбираться в порядке evaluation. Код может быть не таким очевидным.
• использовать функцию ради одной строки:

auto old_name = std::exchange(name_, new_name);

Тут нет какого-то внятного изменения состояния. Просто пачка переприсваиваний.
• swap:

auto old = std::exchange(a, b);
b = old;

std::swap(a, b);

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

Я бы никогда её не юзал.

И хотя пост про то, что так не надо, некоторые из вас про неё не знали и обязательно станут пихать куда не стоит. Окститесь!!

@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.

#perf

Осознанно не пишу ничего про ИИ, но не удержался.

Есть такой хорошо известный в среднего размера (а может даже и в широких) кругах чувак — Антон Самохвалов. Я несколько раз его периодами читал, но так как мои интересы не очень матчились с его контентом, я переставал. Недавно узнал про концепцию, которой я очень хочу с вами поделиться. Про неё ниже. В целом сейчас, я кажется, в каком-то смысле до контента Антона «дорос», так что в этот раз планирую на канале задержаться.

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

Поинт такой: раз сегодня с засилием LLM код становится дешёвым, появляется смысл делать (или даже нет смысла НЕ делать) некоторые оптимизации (да и проекты в целом), за которые раньше ни за что бы никто не сел.
Более того, generic решения уходят в прошлое, потому что имея систему, вы можете три доллара понять, что нужно ВАМ в конкретном случае и наклодить частное решение под ваш конкретный юзкейс. Перф даётся проще, если вы знаете, где его искать.

Примеры:
• посмотрел на конкретный паттерн использования памяти и написал аллокатор ровно под него: https://t.iss.one/itpgchannel/4165
• perfect hash с доработками для фиксированного набора расширений файлов: https://t.iss.one/itpgchannel/4184
• огромная стейт машина, которую наклоденерил за 7 часов: https://t.iss.one/itpgchannel/4313
• научился писать данные максимально эффективно на своё конкретное железо в своём конкретном S3: https://t.iss.one/itpgchannel/4484
• тут Антон и сам бы справился, но сэкономил себе нормально так ресурса: https://t.iss.one/itpgchannel/4242

Тут общая концепция словами автора: https://t.iss.one/itpgchannel/4344
и продолжение: https://t.iss.one/itpgchannel/4379

Думаю, вы ощутили, что имелось в виду выше.

Я в последнее время иногда занимаюсь большим проектиком (когда-нибудь вам покажу). И там постоянно натыкаюсь на шероховатости стандартной библиотеки (в которой я вижу general решения, пытающиеся угодить всем). Я постоянно возвращался к мысли, что для перфа частные решения, даже для таких общих вещей, неимоверно важны. А тут оно как-то сматчилось с идеей со стороны и нашло продолжение в связи с ИИ.

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

Человек трудящийся уходит в прошлое. В дело вступает человек думающий. У разработчика без глубокой картины происходящего, с узким кругозором, и агент будет использоваться кустарно, чтобы подпереть да подкрутить. Если вы найдёте способы и силы развиваться качественно в текущих условиях, вы не то чтобы станете легитимными 10х, но и всеми 228х разработчиками.

Качайтесь и читайте Антона: @itpgchannel.

@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.

Хотите advent about bad parts стандартной библиотеки в декабре? Если хотите, тыкайте 🌚. Если нет: 🗿.

#highload

Давайте представим, что у вас есть пару датацентров и по какой-то причине вы потеряли некоторые. Чуть ли не все. Что делать?

Конечно, не дай бог кому-то попасть в такой кризис.

Но план выживания примерно такой:
• определить критический функционал и операции, которые необходимо поддержать любой ценой. Сфокусироваться на этой части ваших сервисов. Остальные выключить для максимальной экономии ресурсов. В идеале, вы должны знать критическую цепь в любой момент жизни продукта.
• увести нагрузку (если есть что уводить) на работающее и доступное железо
• активно позабирать ресурсы там, где они используются неэффективно, и отдать туда, где их критически не хватает (в идеале это всегда должно выполняться, но достичь этого сложно). Восстанавливать сервисы надо по приоритетам, а не наобум.

В такой ситуации (как и во многих других) жизненно необходимо уметь правильно функционально деградировать. Вспомним пост от начала года: https://t.iss.one/thisnotes/399

Год назад примерно в окрестности этого времени я активно исследовал, что нужно сделать, чтобы иметь инструмент вида «по кнопке отключить всё кроме самого важного». К сожалению, бизнес устроен так, что такими долгосрочными вещами заниматься почти наверняка нельзя. Это всегда nice to have. До тех пор, пока попа не отвалится (конечно, и я мог бы лучше продавать проекты, но как есть). Прийти к чему-то материальному и полезному не получилось.

Ну что ж.

@thisnotes. Patreon (сюда можно донатить, чтобы мои дц жили вечно), newsletter.
Спасибо Artyom Garkavy и niki4smirn.