C++ итераторы

http://stackoverflow.com/questions/2616643/is-there-a-standard-cyclic-iterato...

> инкремент итератора, указывающего на end() даёт begin(),

а декремент - последний элемент?

Это такая шутка?

лицоладонь

стоит почитать умные книжки по STL, да.

Это «теоретическое предположение» или «из практики»?

Если второе, то как Вам это удалось?!?!?!

Единственный источник которому стоит доверять это стандарт языка С++. Описанного вами поведения итераторов я в стандарте не встречал.

А разве не должен быть NULL в обоих случаях?

> А разве не должен быть NULL в обоих случаях?

Eddy_Em, идите и читайте книжку по плюсам.

Второе верно.

идите и читайте книжку по плюсам.

Лет 7 назад читал. Нафиг, нафиг...

> Нафиг, нафиг...

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

Неужели 2011 год объявили годом C/C++? Откуда такой всплеск топиков по С/C++?

> Неужели 2011 год объявили годом C/C++? Откуда такой всплеск топиков по С/C++?

лоровцы наконец-то решили заняться делом, а не написанием очередного вычисления факториала на маргинальных языках

> Единственный источник которому стоит доверять это стандарт языка С++.

Ага, особенно в местах про, которые из него выпали.

Аноним, неужели единственное, что ты прочитал и запомнил — это стандарт C++, что ты постоянно всюду им тыкаешь?

>Где-то документировано что инкремент итератора, указывающего на end() даёт begin()
Внезапно! Откуда дрови^Wтрава?

> Аноним, неужели единственное, что ты прочитал и запомнил — это стандарт C++, что ты постоянно всюду им тыкаешь?

У вас есть другой первоисточник информации по С++?

> Ага, особенно в местах про, которые из него выпали.

Интересно, какой источник информации восполняет эти пробелы?

> Интересно, какой источник информации восполняет эти пробелы?

Очевидно, их заполняют особенности реализации. Некоторые писатели компиляторов даже специально их документируют.

Где-то документировано что инкремент итератора, указывающего на end() даёт begin(), а декремент - последний элемент? Или это вообще не гарантируется?

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

Для stl::list::iterator это действительно так, но вообще то итераторы встречаются много где, и ждать такого поведения от всех итераторов я бы не стал;-)

Именно для std::list::iterator. Оно работает, но меня интересует насколько можно на это опираться и насколько это справедливо для других контейнеров.

Ну тупым методом проб устанавливается, что для stl::map и stl::vector это не так. Кроме того, как выше отмечалось для обычного массива это тоже не так. Для list это IMHO скорее баг чем фича, некая особенность реализации - во вяком случае я ничего такого в описании не припоминаю.

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

> насколько можно на это опираться

Опираться на это ни в коем случае нельзя. Стандарт определяет итераторы ввода, вывода, однонаправленные, двунаправленные, произвольного доступа. Никаких «циклических» итераторов Стандарт не определяет.

Тем более, что в отладочной версии STL будет генерироваться ошибка.

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

Откуда столько негатива? Я лишь хотел поддержать тебя.

Негатива не было, было непонимание.

Насколько я знаю, реализация GNU использует как циклические итераторы. Если отладочная версия GNU STL предупреждает о подобных ошибках, то это правильно.

К слову, итераторы являются шаблонами, то есть не могут быть скомпилированы сами по себе, без инстанцирования. Что нужно сделать, чтобы воспользоваться отладочной версией STL?

Таких отладочных версий STL может быть несколько. Например, STLport в режиме отладки вставляет некоторые проверки.

Ожидаемо оно должно падать с исключением, но на практике иногда вылезает странное поведение да. А посему верить только стандартам

> А посему верить только стандартам

Неправильный совет. Верить вообще ничему нельзя.

В итоге-то что? Гнушники насрали отсебятины без документации (в M$-стиле), или вы просто не знаете где документацию искать? Не там я вопрос задал, видимо.

> Верить вообще ничему нельзя.

Да, верить ничему и никому нельзя. Мне можно.

Где-то документировано что инкремент итератора, указывающего на end() даёт begin(), а декремент - последний элемент?

Это нигде не документировано. Это чьи-то фантазии.

Или это вообще не гарантируется?

Раздел 24.1.1, таблица 72:

Operation: ++r
Type: X&
Semantic, pre/post conditions: pre: r is dereferenceable; post: r is dereferenceable or r is past-the-end; post: any copies of the previous value of r are no longer required either to be dereferenceable or to be in the domain of ==.

Предусловие: должна быть применима операция разыменования. К итератору past-the-end операция разыменования не применима, потому как «The library never assumes that past-the-end values are dereferenceable».

Для описания операции декремента см. таблицу 75 раздела 24.1.4.

> Semantic, pre/post conditions: pre: r is dereferenceable; post: r is dereferenceable or r is past-the-end

Во, это то что я хотел. Спасибо.