Полезные фичи С++ на примере организации пайплайна

А если использовать в разных библиотеках не саму функцию, а только registry - он будет работать правильно.

Если передать из одной библиотеки registry сформированный в другой, то из-за несоответствия индексов в storage будет получен не тот вектор значений.

В представленном решении используется unordered_map<type_index, any>. Если использовать std::type_index или соответствующий hash_code, то таких проблем не будет.

Полезные фичи С++ на примере организации пайплайна

При такой регистрации типа возможна очень нехорошая ситуация.

При сборке разных библиотек в каждой из них будет своя собственная последовательность индексов type_index, а при сборке приложения вообще другая.

Для примера можно реализовать foolib с методом

void foo ()
{
    ::std::cout << "double:" << type_index<double>::value() << ::std::endl;
    ::std::cout << "int:" << type_index<int>::value() << ::std::endl;
}

затем barlib с методом

void bar ()
{
    ::std::cout << "int:" << type_index<int>::value() << ::std::endl;
    ::std::cout << "double:" << type_index<double>::value() << ::std::endl;
}

а затем в тестовом приложении сделать так

void baz()
{
    ::std::cout << "string:" << type_index<::std::string>::value() << ::std::endl;
    ::std::cout << "vector<int>:" << type_index<::std::vector<int>>::value() << ::std::endl;
}

int main()
{
    foo();
    bar();
    baz();
    return 0;
}

и получить на выходе

double:0
int:1
int:0
double:1
string:0
vector<int>:1

Void me

А как же классический if constexpr? Или enable_if, или requires на сам метод test_running_time? Тогда и boid не потребовался бы. Или у этого типа есть ещё какой то смысл?

Краткий обзор нововведений C++23: deducing this

Так исторически сложилось. Такое соглашение о форматировании кода в большинстве проектов, в которых я участвовал. Похоже, Qt оказал влияние). Но всегда для удобства можно использовать псевдонимы для пространств имен.

namespace scl = ScL;

Краткий обзор нововведений C++23: deducing this

Развиваю библиотеку "умных" оберток https://habr.com/ru/post/650701/ и для меня это нововведение весьма полезно. Сейчас код представляет собой большую портянку макросов (например, здесь https://gitlab.com/ssoft-scl/module/feature/-/blob/main/src/Detail/Operator.h), от которых теперь можно легко избавиться.
Не думаю, что такой стиль будет распространён в прикладных программах, а вот инструментальные библиотеки типа std, boost и др. обязательно это будут использовать.

Добавляем дополнительные особенности реализации на C++ с помощью «умных» оберток

Если "потокобезопасность" это добавление на каждую операцию лока, то это не потокобезопасность

Средства библиотеки позволяют сделать операцию lock, как на каждую операцию отдельно, так и на любой блок кода, в зависимости от желаний разработчика. На постоянной основе сейчас можно сделать блокировку так

using Map = Wrapper< map, ThreadSafe::RecursiveMutex >;
Map map;

void foo ()
{
    // в месте, где нужен постоянный lock
    auto map_ptr = &map;
        // map_ptr - умный указатель, который выполнил lock
    if ( map_ptr->empty() )
        map_ptr->doAnything();
}

Добавляем дополнительные особенности реализации на C++ с помощью «умных» оберток

Не откладывая в долгий ящик, всё в проекте поправил. Спасибо за замечание, действительно глаз режет.

Добавляем дополнительные особенности реализации на C++ с помощью «умных» оберток

Кодстайл ужасный, читать очень тяжело.

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

for ( const auto & value : values )
        cout << value << endl;

Как раз над этим сейчас и работаю).

Добавляем дополнительные особенности реализации на C++ с помощью «умных» оберток

Подход strong typedef к простой декларации новых типов на основе существующих известен достаточно давно и имеет свою реализацию, например, в Boost.
Здесь показана возможность реализации такого подхода с помощью "умной" обертки на основе примера из доклада на коференции CppCon 2018.

И FileName и Url являются отдельными типами, а не синонимами. В этом весь смысл.