Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Object next() возвращает элемент над которым "пролетает" итератор.
VD>Не выдумывай. next() просто переходит к следующему элементу. При этом в начале итератор находится в состоянии перед первым элементом, а в конце на последнем.
Зуб даешь? (У меня тут уже коллекция "Зубы титанов" намечается)
The next() function returns the item that it jumps over.
The diagram below illustrates the effect of calling next() and previous() on an iterator:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Вот меня и инетересует это самое "а что-то другое": що ж це воно такэ, г`а? CS>>Это примерно как приделать seekg с stream. Эх глянуть бы в глаз тому кто это придумал.
VD>Потоки бывают разными. Бывают поледовательными, а бывают с произвольным доступом. Точно так же как списки. Бывают списки на связанных списках, а бывают на массивах.
"Потоки ... бывают с произвольным доступом."
Массивы бывают. Потоки нет. По определению.
"Нельзя войти в одну реку (в один поток) дважды",
(С) Гераклит, 510-512 Anno Domini.
Здравствуйте, VladD2, Вы писали:
VD>Итераторы в Яве указывают точно так же на элемент. Только в отличии от СТЛ-я они стаоят на вымышленном (несуществующем) элементе не в конце, а в начале. Плюс в них есть понятие HasNext. Вот оно то и дает большее удобство и простоту. И вообще итераторы СТЛ слишком громоздки.
Для справки:
Unlike STL-style iterators, Java-style iterators point between items rather than directly at items. For this reason, they are either pointing to the very beginning of the container (before the first item), at the very end of the container (after the last item), or between two items.
Здравствуйте, VladD2, Вы писали:
MS>>Честно сказать, мне концепция итераторов вообще не нравится. VD>...
VD>Судя по поскипанному тебе не концепция (паттерн) "итератор" не нравится, а его убогая реализация в СТЛ. Вот в Яве как раз они и сделаны по человечески. Их нельзя гонять назад. Нельзя менять и т.п.
А в STL — не восходящая иерархия итераторов (от простейшего input/output до крутейшего random), а деградирующая иерерхия указателей (с постепенным наложением ограничений: дешёвая арифметика, дорогая арифметика, затем запрещение декрементов, и наконец, жёсткий протокол)
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Шахтер, Вы писали:
Ш>> В stl есть несколько категорий итераторов. Наиболее важная и употребимая -- random access итераторы. Остальные категории получаются удалением некоторых способностей из RanIt.
MS>В том-то и дело, что идеологически, понятие random access iterator является само-противоречивым. Либо random access, либо итератор. По-моему, так.
Ну почему же. Это просто разные способы применения. Указатель, скажем, позволяет и итерировать, и произвольный доступ. Причем естественным образом.
MS>И это не демагогия. Из за стремления впихнуть все сущности в одно понятие, появляются все эти неуклюжие traits & policies, в то время, как сущности просто-напросто принадлежат к разным категориям.
Дело не в стремлении впихнуть все сущности в одно понятие, а в природе вещей. Голый указатель обладает набором определённых свойств -- вот эти свойства и были аксиоматизированы. Получился randon access iterator. Тебе же волновое уравнение не кажется неестественным?
MS>Зачем, скажем сортировке итераторы?
Не итератор, а randon access iterator. А иначе она становится неэффективной.
MS>Сортировке от контейнера требуется две вещи — аксессор и размер.
Сортировке вообще не нужен контейнер -- ей нужен интервал, причем, желательно, с произвольным доступом.
Я отношу фразу "random access iterator" к разряду хохм
типа "старый опытный камикадзе"
Итератор — это итератор. Random access это нечто абсолютно противоположное.
---------------------------
В D есть понятие slice:
char[] range = "Hello world";
foreach(char c; range) { writef("%c", c); }
range = range[0..5]; // slicing
foreach(char c; range) { writef("%c", c); } // та же самая операция но уже над slice
Т.е. с точки зрения D массив и диапазон это одно и то же.
Такие решения возможны по всей видимости только "под GC".
В принципе можно и на C++ что-то на эту тему придумать с подсчетом ссылок но
думаю коряво получится.
Здравствуйте, VladD2, Вы писали:
VD>Судя по поскипанному тебе не концепция (паттерн) "итератор" не нравится, а его убогая реализация в СТЛ.
Влад, тебе хотя бы знаком смысл слова "убогий"? Посмотри в толковом словаре, если что. Реализацию итераторов в STL можно назвать какой угодно, но только не убогой. Наоборот, она слишком наворочена. При этом пользоваться итераторами легко и просто. А вот написать правильный итератор — иногда застрелиться можно, сколько там всего надо учесть.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Шахтер, Вы писали:
Ш>Ну почему же. Это просто разные способы применения. Указатель, скажем, позволяет и итерировать, и произвольный доступ. Причем естественным образом.
Ш>Дело не в стремлении впихнуть все сущности в одно понятие, а в природе вещей. Голый указатель обладает набором определённых свойств -- вот эти свойства и были аксиоматизированы. Получился randon access iterator.
Воот! random access iterator — это pointer и есть. Надо было так и назвать его — pointer, а не итератор. При этом поинтер обладает всеми свойствами итератора, но итератор не обладает некоторыми свойствами поинтера. И всех делов. Сортировка требует именно поинтеров. С итераторами она работать не умеет. При этом вектор имеет поинтеры, а список — итераторы. И никаких полисей.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Судя по поскипанному тебе не концепция (паттерн) "итератор" не нравится, а его убогая реализация в СТЛ. Вот в Яве как раз они и сделаны по человечески. Их нельзя гонять назад. Нельзя менять и т.п.
И чем же не устраивает возможность гонять назад и т.п.?
[]
Ш>> В stl есть несколько категорий итераторов. Наиболее важная и употребимая -- random access итераторы. Остальные категории получаются удалением некоторых способностей из RanIt.
MS>В том-то и дело, что идеологически, понятие random access iterator является само-противоречивым. Либо random access, либо итератор. По-моему, так. И это не демагогия. Из за стремления впихнуть все сущности в одно понятие, появляются все эти неуклюжие traits & policies, в то время, как сущности просто-напросто принадлежат к разным категориям. MS>Зачем, скажем сортировке итераторы? Сортировке от контейнера требуется две вещи — аксессор и размер. То есть, operator[] и size(). Все, больше ей ничего не надо. MS>
MS>sort(container);
MS>
MS>Если же надо отсортировать в диапазоне, делаем это через простейший-простейший адаптор: MS>
MS>sort(range(container, 10, 20));
MS>
Использование operator[] для range(range(...)) может не в лучшую сторону сказаться на производительности, в то время как с парой random итераторов такой проблемы нет. Да и forward iterator или его подобие все равно пришлось бы определять.
MS>При этом у нас автоматически запрещено сортировать списки. А в STL, для того, чтобы запретить сортировку списков, приходится городить дополнительный огород с полиси. Короче говоря, итераторы в STL и тем более в Boost — это пример ненужного усложнения, "типа круто".
Для итераторов более низкого уровня чем random просто не определены операторы + и -, так что списки запрещено сортировать и без огорода с полиси.
Здравствуйте, c-smile, Вы писали:
CS>Профессор, мое субъективное восприятие нижеприведенной фразы не позволяет мне объективно CS>(ака "канкретно") насладиться прелестью оной.
К>>Итераторы Java (а также энумераторы COM) — это обобщение идеи сканера файла: доступ к объекту приводит к смене состояния субъекта.
CS>Что в данной сентеции есть "объект", а что "субъект"?
Здравствуйте, Кодт, Вы писали: К>Однако, мешает. sort нуждается в итераторах произвольного доступа (с дешёвой арифметикой). Конечно, можно определить её через advance — но это будет очень дорого стоить. Вместо O(n*log(n)) получим что-то кубическое.
А это смотря какой сорт. Если обратиться к Кнуту III, то можно найти штук десять всяких сортировок. И в основном они отличаются как раз требованиями к нижележащему интерфейсу. В частности, значительная доля отведена сортировке потоков.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Кодт, Вы писали:
К>А в STL — не восходящая иерархия итераторов (от простейшего input/output до крутейшего random), а деградирующая иерерхия указателей (с постепенным наложением ограничений: дешёвая арифметика, дорогая арифметика, затем запрещение декрементов, и наконец, жёсткий протокол)
Это мягко говоря не итератор. Итератор — это паттерн описанный в GoF. В яве тоже есть IList и т.п. Но к итераторам это отношения не имеет.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Влад, тебе хотя бы знаком смысл слова "убогий"? Посмотри в толковом словаре, если что.
Ты бы сам залез и глянул, чем выпендриваться. Чтобы облегчить тебе жизнь скажу, что одно из значений "жалкий на вид, изувеченный".
MS> Реализацию итераторов в STL можно назвать какой угодно, но только не убогой. Наоборот, она слишком наворочена.
Хех. К итераторам "итераторы СТЛ" отношения не имеют. А так конечно. Потому и убогий, или если тебе будет угодно, уродливый.
MS>При этом пользоваться итераторами легко и просто. А вот написать правильный итератор — иногда застрелиться можно, сколько там всего надо учесть.
Ненадо. Им и пользоваться не очень удобно. Это довольно невнятное извращение. Явовские итераторы просты и логичны. В Шарпе вообще паттерн введн в язык. Его и реализовывать легко и использовать. Во втором шарпе итераторы вообще как орешки щелкаются (yield-ом).
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Костя Ещенко, Вы писали:
КЕ>И чем же не устраивает возможность гонять назад и т.п.?
Несоотвествованием сути паттерна. Про бритву Окама слышал?
Грамотное деление было бы следующим:
Итератор — перечисление.
Коллекция — возможность узнанать количество элементов и возможности получения их списка.
Список с произвольным доступом — произвольный доступ к элементам.
Причем каждая последующая абстракция должна поддерживать возможности предыдущей.
Именно так и сделно в дотнете (IEnumerable<T>, ICollection<T>, IList<T>). К сожалению тоже не очень грамотно. Так как в интерфейсы коллекции и списка введены методы модификации, а по мне так они должны размещаться в отдельных интерфейсах.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>foreach (SomeType elem in SomeTypeCollentin)
VD>> ....
MS>
VD>>И луче хотя бы потому, что не нужно распознавать паттерн. Вместо этого можно просто оперировать понятием перечесления.
MS>Это декларативное программирование.
Отнюдь. Это чистый императив. Декларативное это как-то так:
MS> Я вижу здесь скрытую проблему. Перебор всех элементов в любом контейнере должен иметь сложность O(N). А из подобной записи это совсем не очевидно.
1. Никто ничего никому не должен. Например, при переборе элементов дерева O(n) получить сложно (хотя в принципе можно, как например в BTree+).
2. Любой разумный разработчик стремится сделать свою реализацию итератора максимально эффектинвной. Так что в 99% случаев времянные характиристики действительно будут порядка O(n).
MS> Не превратиться ли этот foreach в O(N log N) или того хуже в O(N^2)? Скорее всего не превратится, но это неочевидно и создает дискомфорт. Точно так же, как оптимизатор скорее всего соптимизирует код, но никаких гарантий дать не может.
Этот дискомфорт из догм и привычки жить на уровне битов. Между тем все просто. Если общие характиристики участка код оказались не приемлемыми, то с помощью профайлера или ручных измерений можно очень быстро найти и устранить проблему. А не постоянно заморачиваться скоростью теря при этом (сильно теряя) скорость разработки.
Кстати, мой опыт показывает, что на самом перечислении скорость не теряется. Она теряется тогда когда вместо поиска со скоростными характеристиками типа O(1) или логарифмических использовались переборы. Вот на этом действительно можно любой алгоритм подвесить.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет: > VD>>foreach (SomeType elem in SomeTypeCollentin) > > VD>>И луче хотя бы потому, что не нужно распознавать паттерн. Вместо > этого можно просто оперировать понятием перечесления. > > MS>Это декларативное программирование. > > Отнюдь. Это чистый императив. Декларативное это как-то так: > > SomeTypeCollentin.ForEach(delegate(SomeType elem) { ... });
А разница в чем?
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, c-smile, Вы писали:
CS>Для справки:
CS>
CS>Unlike STL-style iterators, Java-style iterators point between items rather than directly at items. For this reason, they are either pointing to the very beginning of the container (before the first item), at the very end of the container (after the last item), or between two items.
CS>Ссылка на источник в первоначальном сообщении.
Для спрвки, чтобы индусам объяснить казалось бы простые и очевидные вещи приходится придумывать вот такую белеберду. Но ты-то вроещ не индус? Тогда должен понимать, что целочисленный индекст не может быть между элементами.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Перекуём баги на фичи!
