Здравствуйте, kan, Вы писали:

kan>Kluev wrote:

>> ЮБ>Ты себе представляешь stl без итераторов?
>> Цель итераторов — сделать перебор элементов в разных контейнерах
>> одинаковым. Это больная идея т.к. контейнеры должны перебиратся наиболее
>> нативным для них способом. Как например должен выглядеть итератор для
>> многомерных массивов, кольцевых списков и деревьев? Многие контейнеры в
kan>Делается просто — несколько типов итераторов. Классический пример — begin-end/rbegin-rend. Для дерева можно 2 типа
kan>сделать — обход в ширину и обход в глубину.

Не юзабельно. Т.к. рекурсия в данном случае проще и лучше.

kan>Т.е. функции, возвращающие итераторы могут быть даже с аргументами, например, задать по какой "кривой" обойти
kan>многомерный массив.

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

>> концепцию итераторов просто не вписываются в результате чего программист
>> вынужден пользоватся тем убогим набором который есть в stl. К томуже
>> алгоритмы применимы не ко всем контейнерам и фактически единственным
>> универсальным алгоритмом который подходит для всех является for_each. Но
>> для этого существует более универсальный и могучий паттерн — визитор,
>> который:
>>
>> 1) гораздо проще в реализации чем итератор
>> 2) программы с его использованием получаются более элегантными
kan>Требует задания функтора. Всегда. А это не всегда элегантно.

Не всегда. в контейнере просто заводятся функуци с визитором и без.

kan>Не позволяет иметь несколько итераторов, позволяющих обходить контейнер в разном порядке одновременно.

Для этого есть обычные циклы которые как раз для этих вещей и предназначены. Чтобы ходить как хочешь и куда хочешь.

>> Третье преимущество в том что внутри container.clear(clear_func) пербор
>> идет способом родным для контейнера, что существенно упрощает отладку.
kan>Какой способ является родным для дерева? Да даже для того же массива? Почему от начала к концу, а не наоборот? Или с
kan>середины к краям?

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

>> Так же итераторы в стиле stl совершенно не подходят для перебора
>> кольцевых контейнеров.
>> Т.к. в силу замкнутости их требуется итерировать не в диапазоне [begin,
>> end), а в диапазоне [begin, last]
kan>[begin, last] никак не позволяет задавать пустые интервалы, и никак это не обойти, и это является наиболее важным. Тем
kan>более не надо делать замкнутый итератор единственно доступным для контейнера. Пусть это будет обычный std::list, просто
kan>для него создать ещё один тип итератора, который будет замыкаться.

Это как? На каждой итерации проверять не в конце ли мы и если в конце то переходить на первый элемент? Значит ради идей уже пожертвовали удобством и отладкой, а теперь вот еще и на производительность плевать. Не самая лучшая идея. Более того такое решение все равно будет более неудобным чем специализированный контейнер.