LINUX.ORG.RU

[C++] Итераторы

 


0

1

Пишу свой контейнер с D&D и толкиенистками. Где можно почитать про то, как пишутся итераторы и какие требования накладывает на итераторы STL? Желательно по русски и не в общем (если меня отправят в книгу «Итераторы в C++» о шестиста страницах, я буду только рад).

★★★★★
Ответ на: комментарий от mono

Все знакомые мне книги по STL (или другим библиотекам контейнеров) не рассказывают что у контейнеров внутри. Я готов почитать хорошую книгу по STL, но мне таковые не знакомы.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от yoghurt

Ну, разве что специфика для STL там может не освещаться (на вскидку не скажу)

yoghurt ★★★★★
()

А чем тебя не устроили существующие контейнеры?
По теме:
Итератор - это что-то вроде умного указателя, т.е. объект, который ведет себя как указатель. Его реализация сильно зависит от твоего контейнера. Самые азы разжевываются например в этой книге. Но естественно только азы, там нет подробного руководства «как написать свой контейнер».

m0rph ★★★★★
()
Ответ на: комментарий от KblCb

Исходники libstdc++ 100% рассказывают, что у контейнеров внутри. Звучит толсто, зато правда.

Как вариант, можно посмотреть оффдоки по тому же libstdc++. Это почти что "книга по STL". Справочник. На инглише только.

Zloddey
()
Ответ на: комментарий от yoghurt

Понятие итератора очень старое, гораздо старше объектно ориентированного программирования, паттернов, а также идей обобщённого программирования, возникших у Степанова, и соответственно, STL.

Довольно ранний пример их использования, хоть и своеобразного - в системе PLASMA из MIT. (Hiewitt, Smith, A PLASMA Primer, 1975.)

Используются они и в работе Sussman, Steele, SCHEME - An interpeter for extended lambda calculus, MIT Ai Memo 349, 1975.

Может о них есть и более ранние упоминания, но сейчас уже трудно вспомнить.

anonymous
()
Ответ на: комментарий от anonymous

>Понятие итератора очень старое

Логично, учитывая тот факт, что сами паттерны как таковые появились в результате обобщения накопившегося опыта :)

yoghurt ★★★★★
()

Так вроде есть такая книга

Мэтью Уилсон - Расширение библиотеки STL для С++. Наборы и итераторы.

Смотрите, наверное там есть.

anonymous
()
Ответ на: комментарий от KblCb

>не рассказывают что у контейнеров внутри

Почитать исходники STL. Не?

Ну и прозреваю, что мусье планирует занятся велосипедизмом.

anonymous
()
Ответ на: комментарий от anonymous

Смысл велосипедизма в том чтобы получить вектор который мог бы вернуть константный указатель на такой же вектор содержащий данные из определённого диапазона данных предыдущего вектора. Данные, понятное дело, у обоих контейнеров общие.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от KblCb

>Смысл велосипедизма в том чтобы получить вектор который мог бы вернуть константный указатель на такой же вектор содержащий данные из определённого диапазона данных предыдущего вектора. Данные, понятное дело, у обоих контейнеров общие.

В бусте вроде было что-то подобное

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

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

KblCb ★★★★★
() автор топика
Ответ на: комментарий от yoghurt

Здорово. «Шаблоны в C++» мне понравились. Буду искать эту.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от KblCb

Смысл велосипедизма в том чтобы получить вектор который мог бы вернуть константный указатель на такой же вектор содержащий данные из определённого диапазона данных предыдущего вектора. Данные, понятное дело, у обоих контейнеров общие.

эм, чёт совсем плохо пахнет... а какую задачу решаете? а то навскидку видится что не вектор надо возвращать, а начало и конец требуемого диапазона в виде итераторов (на худой конец из них скрутить вектор)

как это когда «данные, понятное дело, у обоих контейнеров общие» у меня не очень в голове укладывается, зачем тогда 2 контейнера и как это будет выглядеть?

франкенштейно-велосипед

shty ★★★★★
()
Ответ на: комментарий от shty

Есть класс A, содержащий вектор и реализующий его интерфейс. Итераторы для A указывают на элементы вектора. У класса A есть защищённый конструктор (помимо публичного, который, скажем, такой же как и у вектора) который требует два итератора (начальный и конечный). Экземпляр созданный защищённым конструктором не создаёт своего вектора, а лишь изменяет поведение итераторов так чтобы они ходили по элементам того объекта из которого и вызван защищённый конструктор в заданном интервале. Дабы не случилось плохого, мы запрещаем изменять объект созданный защищённым конструктором. Что тут плохого, я не понял.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от KblCb

Есть класс A, содержащий вектор и реализующий его интерфейс. Итераторы для A указывают на элементы вектора. У класса A есть защищённый конструктор (помимо публичного, который, скажем, такой же как и у вектора) который требует два итератора (начальный и конечный). Экземпляр созданный защищённым конструктором не создаёт своего вектора, а лишь изменяет поведение итераторов так чтобы они ходили по элементам того объекта из которого и вызван защищённый конструктор в заданном интервале. Дабы не случилось плохого, мы запрещаем изменять объект созданный защищённым конструктором. Что тут плохого, я не понял.

котлеты, мухи, куски досок, 2 топора и всё залито клеем и кленовым сиропом, а так ничего...

для чего нужно такое?

//пора смотреть http://sourcemaking.com/antipatterns

shty ★★★★★
()
Ответ на: комментарий от shty

У меня есть порядка ста тысяч точек представляющих спектр. Есть логика рисующая точки, есть логика анализирующая точки. Пользователь не заинтересован в том чтобы анализировать весь диапазон точек. Его интересует только участок который он выбрал. Сравнительно не большой. Тысяч десять точек. Просто обрезать начальный контейнер плохо - весьма возможно что потребуется повторный анализ данных в ином интервале. Копировать их очень не хочется, потому как время и не нужно (анализ не деструктивен). Тащить итераторы в логику, а также явное разделение того что вот это весь контейнер, а вот это его отрезок не хочется потому как не красиво.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от KblCb

У меня есть порядка ста тысяч точек представляющих спектр. Есть логика рисующая точки, есть логика анализирующая точки. Пользователь не заинтересован в том чтобы анализировать весь диапазон точек. Его интересует только участок который он выбрал. Сравнительно не большой. Тысяч десять точек.

ок

Просто обрезать начальный контейнер плохо - весьма возможно что потребуется повторный анализ данных в ином интервале. Копировать их очень не хочется, потому как время и не нужно (анализ не деструктивен).

тут полностью согласен

[..] явное разделение того что вот это весь контейнер, а вот это его отрезок не хочется потому как не красиво.

тут полностью согласен

Тащить итераторы в логику [..] не хочется потому как не красиво.

это почему ещё? в stl почти все алгоритмы на этом построены

shty ★★★★★
()
Ответ на: комментарий от shty

Итераторы неизбежное зло. С ними очень легко допустить трудноуловимую ошибку. Посему я стараюсь выносить работу с ними в алгоритмы или специальные классы-обёртки внутри которых ошибиться с ними гораздо сложнее. Мои алгоритмы как правило перегружены и могут принимать ссылку на контейнер, что и натолкнуло меня на идею возвращать вместо пары итераторов (что само по себе не очень аккуратно) контейнер.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от KblCb

>Итераторы неизбежное зло. С ними очень легко допустить трудноуловимую ошибку.
Так же как и указатели. С++ вселенское зло.

Booster ★★
()
Ответ на: комментарий от KblCb

Итераторы неизбежное зло

опа! а я то думал что итераторы - мощная и гибкая концепция... спасибо что просветили

С ними очень легко допустить трудноуловимую ошибку.

нет, если следовать определённым правилам

Мои алгоритмы как правило перегружены и могут принимать ссылку на контейнер

откройте-ка Вы stl (файлик algorithm), посмотрите как пишутся алгоритмы и не выносите больше никому мозгА

что и натолкнуло меня на идею возвращать вместо пары итераторов (что само по себе не очень аккуратно) контейнер.

во! только это будет не контейнер, а, скажем, класс-адаптер, который хранит 2 итератора и позволяет обращаться с ними как с реальным контейнером (нюансы всё же будут правда). правда у меня всё равно сомнения, зачем итераторы по 10 раз оборачивать с учётом того что во всем алгоритмах пусть даже и не на входе, а внутри таки используются итераторы???

может просто весело и непринуждённо создать класс pair (к примеру) который и будет хранить Ваши пары итераторов (по секрету - он уже есть в stl)?

shty ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.