спасибо, на скорую руку не получилось найти информацию

?
Item 29:Assume that move operations are not present, not cheap, and not used.

А есть ли примеры имплементации unique() для лупхолов до C++20, работающие стабильно на всех компиляторах? Кажется, все найденные мной чужие примеры не универсальны, но если я что-то пропустил – прошу подсказать

Что касается моей попытки сделать это – кажется, получилось, работает на всех трёх компиляторах с C++11.

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

Т.е. в целом, идеи этого видео вполне имплементируемы уже в C++11, C++20 с decltype([]{}) для этого не обязателен

Я же правильно понимаю, что если использовать в шаблоне non-type параметр, то он будет генерить класс для каждого значения этого параметра?
Например

template<int, typename T> templClass;
сделает 2 класса для templClass<1, A> и templClass<2, A>;

template<int, typename T> templClass;
сделает 2 класса для templClass<1, A> и templClass<2, A>;

Правильно понимаешь

Извините если вопрос слишком широкий. Меня интересуют книги уровня library developer. Что читать , если гипотетически я хочу создать что то уровня boost.spirit?

Конечно в действительности я этого делать не буду, но по книжкам читнул бы

Решил слепить еще одну статью. Надеюсь, нигде сильно не облажался
https://habr.com/ru/post/493808/

бросилось в глаза - жутковатый sfinae, который заменяется на requires sizeof...(T) == 0 (раз уж статья про C++20 с корутинами)

"Для начала нам нужно создать простенький акторный фреймворк"

ну ёпрст нормально же общались...

Возможно, до концептов пока не дорос

А что не так?

ну хз, "пообщавшись" с акторами начинает казаться что у всех разное понимание того что вообще есть актор, для чего оно надо и т.д.

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

И как бы она по ним "прыгала"? Я не представляю, как это сделать не в рамках акторов. Ну тоесть все равно в итоге получится что-то похожее на акторы, почему бы тогда это акторами и не назвать?

это скорее называется executor. Например у нас тред ждет значение из корутины и получая его направляет корутину в соответствующий поток

а внутри корутины простое

yield ProcessingThread; // чтобы перейти в поток обработки

Это видимо что-то похожее на это?
https://habr.com/ru/company/yandex/blog/420861/
Я немного опирался на этот доклад, но сам подход показался мне странным. Поэтому сделал так, как лично мне показалось более естественно