Средства для работы с итераторами

А ты именно готовое ищешь или спрашиваешь как лесопед запилить?

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

По идее, можно посмотреть в сторону прикручивания проверок из concept части boost::iterator.

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

Только готовое. Ничего не нагуглив, запилил свой велосипед. Он, быть может, и работает, но на первом же тесте компиляторы дружно сказали ПНХ. Коль я на этом тормознулся, решил заодно спросить - может есть уже. В качестве примера:

std::forward_list<std::array<int,50U>> buf;
...
for (auto i(xbegin(buf));i != xend(buf);++i)
    //traversal int values using *i here

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

наверное, ... не нужно

Возможно, у меня всего один кейс: scatter-gather rw как единственная универсальная возможность(и при том наименее костыльная) работы с буфером переменного размера без просадки производительности при аллокациях(аллокатор для узлов фиксированного размера довольно быстр, а realloc(), очевидно, не всегда может обойтись без повторного выделения всего объёма).

но у тебя всё равно останутся привязки к размерам, либо конечным элементам твоих массивов

Для встроенных массивов, конечно, проблематично будет сделать. Но, imho, они стали не нужны в новом коде с появлением std::array<>(а в boost-е это ещё с древних времён). Остальные контейнеры предоставляют метод size()

Видимо, ничего такого нет. Ушёл допиливать велосипед

ты ничего не выиграешь своими костыльными итераторами поверх. может, даже немного проиграешь в скорости.

единственное, что тебе может помочь увеличить скорость - кастомные аллокаторы из пула для твоих элементов и intrusive контейнеры, элементы которых можно собирать в разные списки в любом порядке.

ничего не выиграешь

Так это не для скорости, а чтобы каждый раз не писать

for (auto& sub:c)
    for (auto& item:sub)
    {
        ...
    }

отношение упорядочения категорий, чтобы можно было написать что->то наподобие iterator_category >= std::bidirectional_iterator_tag >в std::enable_if<>

Стандартные категории наследуюся друг от друга, так что можно попробовать

 std::is_base_of<std::bidirectional_iterator_tag, iterator_category>::value