Легален ли декремент итератора полученного от QMap::end()?

а чо бы и нет.

декремент итератора полученного от QMap::end()

нехорошо это

получить последний элемент

QMap::last()

Легален ли декрет императора

Тьфу ты. Ну его нафиг лор на бегу с телефона читать.

Не знаю чувак, даже бы не удивился после стольки лет на ЛОРе

Конечно, QMap::end() возвращает QMap::iterator.

QMap::iterator -> Public Functions -> iterator & iterator::operator–()

Что мешает зайти на doc.qt.io?

на бегу с телефона читать.

Можешь на бегу с мака читать. Think different.

декрет императора

И что? Если итератор двунаправленный, это гарантия легальности декремента от end()?

Все не константные итераторы в qt и так двунаправленные. Все двунаправленные итераторы поддерживают префикс декремента (–). Что здесь может быть «нелегального» не понимаю?!

легален ли QMap::end() если он указывает на элемент после последнего? тук-тук, кто там, с++ полиция открывай.

Что здесь может быть «нелегального» не понимаю?!

Для начала, куда будет указывать --QMap<что-нибудь>::iterator{}?

А теперь, что мешает какому-нибудь автору какого-нибудь контейнера вернуть {} из end()?

А теперь, что мешает какому-нибудь автору какого-нибудь контейнера вернуть {} из end()?

Да, пример не очень удачный, но обратное не документировано. По этому считаю это поводом считать возможность декремента от end() всего-лишь недокументированными возможностями.

По идее нормально всё. Вот, смотрите. Если Вы из пустого множества вызываете end, то он вернет begin (STL style). Т.к. итератор не константный, а двунаправленный, то Вы снова получаете begin.

Я вообще не тестировал, но предполагаю, что работает именно так. Подобные ситуации обрабатывать желательно, конечно.

В Qt сами пользуют std::prev(list.end()).

А теперь, что мешает какому-нибудь автору какого-нибудь контейнера вернуть {} из end()?

То, что это нарушит https://doc.qt.io/qt-5/containers.html#stl-style-iterators:

The end() function of a container returns an iterator to the imaginary item one position past the last item in the container. end() marks an invalid position; it must never be dereferenced.

Т.е. end() должен вести себя как итератор на элемент за последним. Исключение только в том, что его нельзя разименовать, про -- не говорят.

Ну вот это в точку.

А теперь, что мешает какому-нибудь автору какого-нибудь контейнера вернуть {} из end()?

Вчера прочитал иначе, по другому понял смысл вопроса. Ну, уже ответили.

Вот она плюсовость, пришли данные, а что они хрен его знает. Либо данные вычисляемые то только API либо данные блок памяти то хоть API хоть как угодно в рамках формата данных. От ёпрст.

В Qt сами пользуют std::prev(list.end()).

И вот тут находим ответ на вопрос ТС: https://en.cppreference.com/w/cpp/iterator/prev

Although the expression --c.end() often compiles, it is not guaranteed to do so: c.end() is an rvalue expression, and there is no iterator requirement that specifies that decrement of an rvalue is guaranteed to work. In particular, when iterators are implemented as pointers or its operator-- is lvalue-ref-qualified, --c.end() does not compile, while std::prev(c.end()) does.