Здравствуйте, гость ( Вход | Регистрация )
D_K | Дата 22.10.2012, 11:12 |
Неясно, к чему это. | |
Iron Bug | Дата 22.10.2012, 7:15 |
Iron Bug, как вы собираетесь делать erase с reverse_iterator'ом? Это возможно только через метод base(), возвращающий обычный итератор. и чем же он плох? просто erase сам по себе не принимает обратный итератор. но сам итератор от этого ничуть не страдает. вот обычный метод, который работает, удаляя элементы в обратном порядке.
|
|
D_K | Дата 21.10.2012, 23:41 |
Iron Bug, как вы собираетесь делать erase с reverse_iterator'ом? Это возможно только через метод base(), возвращающий обычный итератор. | |
Iron Bug | Дата 20.10.2012, 19:02 |
Iron Bug, так не об этом речь. reverse_iterator'ы обсуждаем. именно об этом. реверс-итератор ничем принципиально не отличается от обычного итератора и у него при вызове erase точно также будут работать префиксные плюсы и не будут работать постфиксные. |
|
D_K | Дата 20.10.2012, 15:54 |
Iron Bug, так не об этом речь. reverse_iterator'ы обсуждаем. | |
Iron Bug | Дата 19.10.2012, 19:56 |
если вкратце, то erase превращает итератор в так называемое singular value. можно представить его как аналог NULL для указателей. это значение, не принадлежащее ни одному контейнеру. поэтому после erase итератор становится невалиден и постфиксная операция iter++ будет невалидна. а вот если взять префиксный плюс (++iter) прямо внутри вызова erase, то всё будет ok, потому что сначала итератор изменится, а его "старое" значение будет скопировано, копия будет использована в erase и перейдёт в singular value. | |
D_K | Дата 19.10.2012, 17:10 |
ИМХО. Стандарт, в первую очередь, предназначен для реализаций языка. И по-моему, вот из этого: Цитата explicit reverse_iterator(Iterator x); Effects: Initializes current with x. ... Iterator base() const; Returns: current ... reference operator*() const; Effects: Iterator tmp = current; return *--tmp; ... pointer operator->() const; Effects: return &(operator*()); ... reverse_iterator& operator++(); Effects: --current; Returns: *this ... reverse_iterator operator--(int); Effects: reverse_iterator tmp = *this; --current; return tmp; следует, что итератор станет невалидным... Кроме того, Iteratir current - это protected-член. Соответственно, это часть интерфейса наследования. |
|
Влад | Дата 19.10.2012, 15:35 |
Тут бы я не согласился. Вот этот самый current - исключительно деталь внутренней реализации реверсивного итератора. И, в то же время, Стандарт иллюстрирует effects через current, но не дает никаких указаний о содержимом current после операций типа erase/insert и о моментах его обновления. В то же время, в Ст.23.2.2.3 (напоминает "Матф. 18:13", не правда ли? :-) ) явно указывает: Effects: Invalidates only the iterators and references to the erased elements. Учтем, что в этот момент reverse_iterator не указывает на erased element, а о его внутреннем устройстве (в том числе, о protected членах) я, как "внешний" пользователь, вообще ничего знать не обязан. :-) А нежелательные эффекты возникают из-за излишне прямолинейного копирования иллюстративного кода в Стандарте - в программный код. Т.е., я имею в виду, что код должен следовать требованиям Стандарта по принципу "включая, но не ограничиваясь". А вот это, видимо, выполняется не во всех реализациях. Дискуссия по этому вопросу и возражения приветствуются! |
|
D_K | Дата 19.10.2012, 15:06 |
Влад, а как же Цитата(24.4.1.1)
Ну и дальше все операции через current расписаны... |
|
Влад | Дата 19.10.2012, 12:10 |
В общем, в результате изучения Стандарта (D_K спасибо за ссылку на 24.4.1) у меня сложилось устойчивое впечатление, что "падающий" код - это следствие косяков конкретных реализаций. Стандарт устанавливает только требования к интерфейсу reverse_iterator, но ничего не говорит о его внутреннем устройстве; это абсолютно нормально. Равным образом, в Стандарте нет требования (requirement) о том, что reverse_iterator обязательно должен содержать iterator, указывающий на предыдущий элемент, - тот самый, который становится невалидным в нашем коде, и основывать свою работу на нем. Таким образом, это остается на усмотрение разработчиков реализации.... К сожалению, в большинстве случаев мы сильно ограничены в выборе реализаций STL. Теоретически, код из поста #10 не противоречит Стандарту и абсолютно валиден (и это тот же самый совет Мейерса #28, только записанный немного подробнее). Однако в конкретных реализациях мы видим, что он не работает. Увы. |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 28.4.2024, 16:23 |