Что-то не так с transform?

transform требует итераторы ввода и делает что-то такое:

И видим здесь:
*first1++

То есть, смещаемся к следующему элементу контейнера, БЕРЁМ СТАРОЕ ЗНАЧЕНИЕ ИТЕРАТОРА, РАЗЫМЕНОВЫВАЕМ... То же самое слева от присваивания. Но: если значение итератора ввода увеличено на единицу, нет никаких гарантий, что его можно
разыменовать по предыдущему значению (с) Прата. Это что же, возможная реализация алгоритма transform с cppreference - неправильная? Или я что-то не так понимаю?

4

Смысл: нельзя сохранять предыдущее значение итератора. Как обеспечить: не использовать предыдущее значение итератора.

Каковы могут быть примеры?
На постинкремент это не распространяется, хорошо. Тогда как он реализован? Приведён, насколько понимаю, псевдокод.

Да так, ни о чём. Если надо объяснять, то не надо объяснять.

0

Сообщение от kozlik_kozlik Можете пример привести?

Привести пример чего?
Ответьте на предыдущий вопрос.

0

Сообщение от castaway Смысл: нельзя сохранять предыдущее значение итератора. Как обеспечить: не использовать предыдущее значение итератора.

И?

Об этом и вопрос! Формально выражение *it++ означает *(it++) и в случае перегруженных операторов * и ++ производится сохранение и использование предыдущего значения итератора после того, как получен инкрементированный итератор.

С точки зрения буквальной интерпретации этого нельзя делать для итераторов класса input iterator. С такими итераторами формально нельзя делать *it++.

Однако в спецификации языка для этих целей сделано специальное замечание, которое добавляет спеициальную трактовку для выражения *it++ в случае input iterator. А именно, такое выражение должно быть экаивалентно

4

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

Где производится? Я не вижу.

0

Сообщение от TheCalligrapher Однако в спецификации языка для этих целей сделано специальное замечание, которое добавляет специальную трактовку для выражения *it++ в случае input iterator. А именно, такое выражение должно быть эквивалентно C++ 1 2 3 { T tmp = *r; ++r; return tmp; }

(см. 24.2.3 Input iterators)

Таким образом исходный код transform корректен, но именно из-за этой специальной обработки выражения *it++ для input iterators.

Общая проблема поднятая kozlik_kozlik действительно имеет место и вопрос задан совершенно справедливый. Ответ на этот вопрос: спецификация стандартной библиотеки содержит "костыль", специально предназначенный для того, чтобы такие случаи работали правильно.

Добавлено через 1 минуту

Сообщение от castaway Где производится? Я не вижу.

Как это где? Внутри реализации постфиксного ++. Постфиксный ++ возвращает старое значение итератора, после чего инкрементирует исходное значение. После этого использовать старое значение уже нельзя. А *it++ посылает это старое значение в оператор *. Отсюда и вопрос.

4

Сообщение от kozlik_kozlik Правильно, если старожил ошибается, это простительно. А новичку можно и нахамить за вопрос. Действительно, чего церемониться.

kozlik_kozlik, вы ответите к чему это было сказано или это клевета?

0

Обратите, кстати, внимание, что спецификация языка разрешает использование только двух типов выражений с постфиксным инкрементом для input iterators:

* (void)r++ - equivalent to (void)++r
* *r++ - определено специальным образом (см. выше)

То есть на самом деле постфиксный ++ формально бесполезен для input iterators - его результат все равно запрещено использовать. Но ради полезной идиомы *r++ было принято решение внести в спецификацию такой "костыль". Фактически *r++ для input iterators - это атомарная операция со своим индивидуальным определением. Она не распадается на независимые * и ++.

Вопрос kozlik_kozlik не просто правильный, а весьма интересный. Я помню, что читал когда-то что-то на эту тему, но мимоходом не до конца понимал, зачем это нужно. А оказывается вот оно что.

1

Сообщение от TheCalligrapher Постфиксный ++ возвращает старое значение итератора, после чего инкрементирует исходное значение.

Наоборот, сначала икрементирует, потом возвращает старое, которое было сохранено в промежутке

Я в принципе так и думал, что последовательность этих 3 операторов как то должна быть обговорена. Сначала подумал про изменение контейнера. Но, тут, как уже сказал TheCalligrapher, об этом сказано явно в стандарте. Если найти причину, почему так сделано, то все станет понятно.

0

Сообщение от Toshkarik Наоборот, сначала икрементирует, потом возвращает старое, которое было сохранено в промежутке

Да, я неточно выразился, под "возвращает старое" я хотел сказать "сохраняет старое значение для последующего возвращения".

0

TheCalligrapher, разыменование итератора что даёт?

0

Сообщение от castaway TheCalligrapher, разыменование итератора что даёт?

Хм... Разыменование итератора даёт нам то значение, на которое итератор ссылается.

(Но к чему это здесь?)

0

Это я к тому, что вы говорите о "старом" и "новом" значении итератора, хотя этот, уже известный вам кусок кода:говорит что нет никакого "старого" итератора.
Есть значение итератора, а есть значение на которое он ссылается.

0

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

0

Сообщение от castaway говорит что нет никакого "старого" итератора.

Ну так я о том и говорю, что в стандартной билиотеке выражению *r++ для input iterator r придано специальное особенное значение, выражаемое вашим куском кода.

При этом в общем случае выражение *r++ такой семаники не имеет даже отдаленно. В общем случае такое выражение имеет семантику

Вопрос ТС потому и возник, что ТС не знал, что в спецификацию языка для input iterator вписан специальный "костыль", переиначивающий трактовку *r++ именно и только для input iterators.

0

TheCalligrapher, это удивительно:

Сообщение от TheCalligrapher C++ 1 { T tmp = *r; ++r; return tmp; }

А чем плохо:
Временный итератор должен скопировать "предыдущее" значение итератора. Почему инкрементирование должно повлиять на полученный tmp_it ?

0

Сообщение от IGPIGP Почему инкрементирование должно повлиять на полученный tnp_it ?

Потому что так сказно в спецификации input iterator.

Input iterator предназначен для итерования "однопроходных" входных последовательностей. За таким итератором может скрываться поток ввода с клавиатуры или чтения с накопителя на манитной ленте. После того, как вы прочитали данные, вы уже либо принципиально не можете прочитать их снова (нельзя заставить пользователя напечатать еще раз то, что он печатал ранее), либо это слишко дорого (дорого перематывать магнитную ленту назад), либо вы просто настаиваете на однопроходной природе алгоритма.

Размеется, можно предложить хранить считанные данные внутри самого итератора. Тогда будет создаваться иллюзия, как будто через "старые" итераторы можно запросто читать данные. Но это не соответстстует идее итератора. Итератор не должен (не может, не обязан) "кэшировать" читаемые данные внутри себя по многим разным причинам.

Добавлено через 9 минут

Сообщение от Mathist не понимаю почему он сначала инкрементирует, а потом возвращает старое, если постфиксная операция должна увеличивать итератор после вычисления выражения.

Не должна. В спецификации префиксного и постфиксного ++ нет никаких намеков на то, в какой момент происходит модификация операнда.

Спецификации префиксного и постфиксного говорят, что префиксный ++ возвращает новое значение операнда, а постфиксный ++ возвращает старое значение операнда. И все.

А уж как у них там внутри все делается - это не оговаривается. В какой момент постфиксный ++ изменит свой операнд тоже не оговаривается. Главное, чтобы он вернул старое значение.

Поэтому ваше предположение, что постфиксный ++ должен "увеличивать итератор после вычисления выражения" совершенно не обосновано. Ничего подобного никогда в спецификации постфиксного ++ не было.

3

Сообщение от TheCalligrapher Потому что так сказно в спецификации input iterator.

Спасибо, теперь понятно.

0

Сообщение от TheCalligrapher При этом в общем случае выражение *r++ такой семаники не имеет даже отдаленно.

Увы, в обсуждаемой теме не общий случай.

0

Сообщение от castaway Увы, в обсуждаемой теме не общий случай.

Так поэтому-то вопрос ТС и появился, как я его понял. Input iterator - это весьма особенный случай. А реализация transform "почему-то" об этом не беспокоится и спокойно реализует свою функциональность так, как будто ничего особенного в input iterator нет.

0