Причина ограничений `reverse_iterator`
На страница cppreference reverse_iterator нахожу следующее замечание
std::reverse_iteratordoes not work with iterators that return a reference to a member object (so-called "stashing iterators"). An example of stashing iterator isstd::filesystem::path::iterator.
Это утверждение верно? И если да, то почему?
Для меня ограничение не имеет смысла, поскольку я предполагаю, что обратный итератор в основном меняет местами operator ++ и operator -- (и сохраняет базовый итератор на один).
Обновлено: По-видимому, вопрос можно неправильно понять:
Я понимаю, что нам нужна операция декремента один раз для реализации обратного итератора. Спрашивается, почему это не реализовано при создании reverse_iterator. Тогда можно избежать проблемы с хранением итератора. Но очевидно, что это не так, и уменьшение выполняется каждый раз, когда итератор разыменовывается. Почему?
Ответы 1
and stores the underlying iterator off by one
Вот в чем причина. При разыменовании необходимо вызвать итератор «не один за другим», и если уничтожение созданного итератора делает недействительной ссылку, полученную из него (как в случае с хранением итераторов), то это назальные демоны.
Хорошо, я вижу недоразумение. Когда я писал stored off-by-one, я имел в виду, что во время построения reverse_iterator базовый итератор нужно декрементировать. Я понимаю, что нам нужно декремент в какой-то момент для реализации обратного итератора, но я думаю, что это можно сделать один раз во время построения. Тогда проблема, о которой вы говорите, будет устранена. Видимо это не так. Так почему же нельзя использовать итератор с декрементом во время построения? Извините, если вопрос был неясным по этому поводу.
@AndreasH. Поскольку полученный итератор не может быть декрементируемым. Рассмотрим rend(), созданный из begin().
: Значит, вы говорите, что `begin ()` дает не декрементируемый итератор?
@AndreasH. По определению, begin() дает итератор в начало контейнера, нет ничего «перед» этой позицией.