Другое дело, что если нет потребности в совместимости с каким-то алгоритмом, заточенным под существующую модель — то эту совместимость можно не накладывать.
В моем случае (курсора к БД) не-итераторо-совместимый интерфейс — не потому, что итераторо-совместимый было тяжело реализовать, а потому, что существенно лучше соответствует логике юз-кейса. Вотъ.
Здравствуйте, Зверёк Харьковский, Вы писали:
CS>>А что означает CS>>container.begin() + 10 CS>>для котейнера типа list?
ЗХ>Для list — ничего не означает. Я всего лишь привел пример. Пойнт мой был: возможность вызова функции, которая принимает начальный и конечный итераторы, но передать ей не begin и end, а что-то другое; таким образом, обработать лишь часть контейнера.
Вот меня и инетересует это самое "а что-то другое": що ж це воно такэ, г`а?
Это примерно как приделать seekg с stream. Эх глянуть бы в глаз тому кто это придумал.
Профессор, мое субъективное восприятие нижеприведенной фразы не позволяет мне объективно
(ака "канкретно") насладиться прелестью оной.
К>Итераторы Java (а также энумераторы COM) — это обобщение идеи сканера файла: доступ к объекту приводит к смене состояния субъекта.
Что в данной сентеции есть "объект", а что "субъект"?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Шахтер, Вы писали:
Ш>>Согласно картинкам, оба варианта изоморфны.
CS>Наверное. Но не совсем.
Ш>>Вообще, не очень понятно, что значит -- указывать между элементами?
CS>Object next() возвращает элемент над которым "пролетает" итератор.
CS>В Java не требуется специальное значение end CS>так как тест на bos/eos осущесвляется отдельной функцией (hasNext).
CS>
CS>Еще раз — не знаю — хорошо это или плохо. Поэтому и спросил.
Ага. Понятнее теперь. Мне кажется, ты пытаешься сравнить не совсем сравнимые категории. В stl есть несколько категорий итераторов. Наиболее важная и употребимая -- random access итераторы. Остальные категории получаются удалением некоторых способностей из RanIt. Если я правильно понял, итератор в Java ближе всего к понятию Input Iterator. Вот что касается этой категории итераторов, она действительно выглядит несколько искуственно в stl и подход Java ну по крайней мере не хуже.
Здравствуйте, Кодт, Вы писали:
К>Есть такая методология — стрёмное программирование (XP). К>Надо тебе сделать output iterator поверх какого-то фидера — делаешь тяп-ляп, зато совместимо со всеми прочими алгоритмами.
... К>Потом, когда руки дотянутся — переделаешь так, чтобы не было шансов для misuse. К>Да и, в конце концов, стратегии позволят нарожать таких итераторов сколько хочешь. Только один раз грамотно шаблон сделать...
...
А может панам стоит познакомиться с библиотекой Boost.Iterator или хотя бы с частным случаем Iterator Facade? Право слово, ничуть не хуже чем собственные велосипеды получается.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Кодт, я там когда-то обещал статейку по LazyK. Так вот, у меня наконец-то дошли кажется руки этим заняться. Еще актуально или ты уже сам разобрался?
Здравствуйте, alexeiz, Вы писали:
A>А может панам стоит познакомиться с библиотекой Boost.Iterator или хотя бы с частным случаем Iterator Facade? Право слово, ничуть не хуже чем собственные велосипеды получается.
CS>>А что означает CS>>container.begin() + 10 CS>>для котейнера типа list?
ЗХ>Для list — ничего не означает. Я всего лишь привел пример. Пойнт мой был: возможность вызова функции, которая принимает начальный и конечный итераторы, но передать ей не begin и end, а что-то другое; таким образом, обработать лишь часть контейнера.
А это ещё одна попытка "впихнуть невпихуемое". Здесь с помощью пары итераторов задаётся сущность "диапазон" (полуинтервал).
В случае последовательных (forward | bidirectional) итераторов — в зависимости от задачи удобно представлять диапазон как пару итераторов "от" и "до", либо как начало и длину.
Написать адаптер итератора с отсчётом — довольно просто... Скажем, это пара из исходного итератора и счётчика. Концевой итератор — у которого счётчик равен 0 (и все концевые итераторы эквивалентны).
Впрочем, никто не мешает сделать
container_type::iterator begin = container.begin(), limit = begin;
advance(limit,10); // по смыслу - limit += 10
sort(begin,limit);
К>container_type::iterator begin = container.begin(), limit = begin;
К>advance(limit,10); // по смыслу - limit += 10
К>sort(begin,limit);
К>
Однако, мешает. sort нуждается в итераторах произвольного доступа (с дешёвой арифметикой). Конечно, можно определить её через advance — но это будет очень дорого стоить. Вместо O(n*log(n)) получим что-то кубическое.
Здравствуйте, alexeiz, Вы писали:
A>А может панам стоит познакомиться с библиотекой Boost.Iterator или хотя бы с частным случаем Iterator Facade? Право слово, ничуть не хуже чем собственные велосипеды получается.
Итераторы в Яве указывают точно так же на элемент. Только в отличии от СТЛ-я они стаоят на вымышленном (несуществующем) элементе не в конце, а в начале. Плюс в них есть понятие HasNext. Вот оно то и дает большее удобство и простоту. И вообще итераторы СТЛ слишком громоздки.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Честно сказать, мне концепция итераторов вообще не нравится.
...
Судя по поскипанному тебе не концепция (паттерн) "итератор" не нравится, а его убогая реализация в СТЛ. Вот в Яве как раз они и сделаны по человечески. Их нельзя гонять назад. Нельзя менять и т.п.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>а если серьезно — я обычно именно так и пишу. ЗХ>но в последнее время стал сталкиваться с тем, что мне от "итератора" надо нааамного меньше, чем предоставляет концепция итератора stl.
Вдумайся в свои слова "предоставляет концепция итератора stl". Концепция есть концепция. А реализация — реализация. Так что в СТЛ просто неудачная реализация очень правильной концепции.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Object next() возвращает элемент над которым "пролетает" итератор.
Не выдумывай. next() просто переходит к следующему элементу. При этом в начале итератор находится в состоянии перед первым элементом, а в конце на последнем. В СТЛ-но в начале он находится на первом, а в конце за последним. Только и всего. А разница в наличии hasNext.
CS>В Java не требуется специальное значение end CS>так как тест на bos/eos осущесвляется отдельной функцией (hasNext).
ЗХ>Другой вопрос — что нужна такая возможность далеко не всегда.
Это недостаток мышеления. Если подобное необходимо, то прост создашь функцию возвращающую частрый итератор и все. А то что ты показал — это использование итераторов не по назначению. Я бы сказал извращение самого понятия итератора, так как эффективная сотрировка требует произвольного доступа, а итератор принципиально предназначен для перебора по элементу.
Например, в дотнете для подобных целей введено понятие коллекции, что отражается в реализации интерфейса ICollectin. У этого интерфейса есть свойство Count и метод CoppyTo с помощью которых содержимое коллекции можно скопировать в массив и произвести над этим массивом опреации тербующие последовательного доступа.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ЗХ>Для list — ничего не означает. Я всего лишь привел пример. Пойнт мой был: возможность вызова функции, которая принимает начальный и конечный итераторы, но передать ей не begin и end, а что-то другое; таким образом, обработать лишь часть контейнера.
Это уже не итератор. Это извращение. Итератор должен перечислять то что ему положено. Нужно работать с диапазонами возвращай итераторы диапазонов или работай с массивами.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Вот меня и инетересует это самое "а что-то другое": що ж це воно такэ, г`а? CS>Это примерно как приделать seekg с stream. Эх глянуть бы в глаз тому кто это придумал.
Потоки бывают разными. Бывают поледовательными, а бывают с произвольным доступом. Точно так же как списки. Бывают списки на связанных списках, а бывают на массивах.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш> В stl есть несколько категорий итераторов. Наиболее важная и употребимая -- random access итераторы. Остальные категории получаются удалением некоторых способностей из RanIt.
В том-то и дело, что идеологически, понятие random access iterator является само-противоречивым. Либо random access, либо итератор. По-моему, так. И это не демагогия. Из за стремления впихнуть все сущности в одно понятие, появляются все эти неуклюжие traits & policies, в то время, как сущности просто-напросто принадлежат к разным категориям.
Зачем, скажем сортировке итераторы? Сортировке от контейнера требуется две вещи — аксессор и размер. То есть, operator[] и size(). Все, больше ей ничего не надо.
sort(container);
Если же надо отсортировать в диапазоне, делаем это через простейший-простейший адаптор:
sort(range(container, 10, 20));
При этом у нас автоматически запрещено сортировать списки. А в STL, для того, чтобы запретить сортировку списков, приходится городить дополнительный огород с полиси. Короче говоря, итераторы в STL и тем более в Boost — это пример ненужного усложнения, "типа круто".
Вот что сказал Tony Juricic (один из активных пользователей моего mail-листа):
You won't get argument from me here. While I don't mean to say there are
not many very useful classes in BOOST, the sheer amount of dirt you have
to pull in, just to use it, is making BOOST less and less of a library I
would consider for doing anything.
It is IMO becoming a display of the failure of compilers and language
extensions, on the other extreme but in its practical nonsense
complementary to latest MS additions to 'managed C++'.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Очень хорошо. но еще лучше:
VD>foreach (SomeType elem in SomeTypeCollentin)
VD> ....
VD>И луче хотя бы потому, что не нужно распознавать паттерн. Вместо этого можно просто оперировать понятием перечесления.
Это декларативное программирование. Я вижу здесь скрытую проблему. Перебор всех элементов в любом контейнере должен иметь сложность O(N). А из подобной записи это совсем не очевидно. Не превратиться ли этот foreach в O(N log N) или того хуже в O(N^2)? Скорее всего не превратится, но это неочевидно и создает дискомфорт. Точно так же, как оптимизатор скорее всего соптимизирует код, но никаких гарантий дать не может.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Давай, выкладывай!
Перекуём баги на фичи!
