Ага, думал об этом. Если будет затык в этом, так и сделаю. Вообще, в JS самая дорогая операция была это клонирование объектов, а все эти переборы - копейки)

(в среднем)

Среднее и амортизированное разные вещи

а у меня где

В начале

где

это код фреймворка

думаю те кто его писали чет соображают

В чем разница принципиальная?

видимо нет

std::find() (который из algorithm) работает за O(n) для любого контейнера (увидел в видео). И вот вопрос как он std::set/std::map за O(n) проходит ? Там же RB tree под капотом, разве итераторы и их инкремент/декремент не должен "по правилам" binary search tree происходить ?

Да и вообще интересно, а вот инкремент / std::next такого итератора что означает ? std::set же не contiguous контейнер, как он знает откуда значение следущее брать ? Если он получает эту инфу от контейнера, то почему std::find() не сработает за O(logn) ?

Хедер подключен в текущий проект?

msbuild проект?

Или cmake?

std::set<std::string> ids;
    std::for_each(items.begin(), items.end(), [&](auto &&el) {
            if (el.first == "items")
                std::visit([&] (auto &&variant_val) {
                    if constexpr(std::is_same_v<decltype(variant_val), std::string>) 
                    ids.insert(variant_val);
                }, el.second);
    });

Ну короче теперь даже компилит

Итераторы там последовательно обходят все элементы. Откуда logn?

ну штош

Средняя сложность вставки в конец вектора не O(1)

А мне вот интересно как они получают эти элементы