Продолжаем возиться с потоками, в фокусе зрения — потоковые итераторы.
Из 24.5.1
istream_iterator reads (using operator>>) successive elements from the input stream for which
it was constructed.
...
The main peculiarity of the istream iterators is the fact that ++ operators are not
equality preserving, that is, i == j does not guarantee at all that ++i == ++j. Every time ++ is used a
new value is read.
...
The practical consequence of this fact is that istream iterators can be used only for onepass algorithms, which actually makes perfect sense, since for multipass algorithms it is always more appropriate to use inmemory data structures.
Далее, смотрим на постфиксный ++, в отношении которого подозрения естественны:
istream_iterator<T,charT,traits,Distance>& operator++(int)
{
istream_iterator<T,charT,traits,Distance> tmp = *this;
*in_stream >> value;
return (tmp);
}
Создаётся копия итератора, на том же потоке, но из него потом вытаскивается символ! Соответственно итератор, вернувшийся из ++ на самом деле не предыдущий, а тот же самый, за единственным возможным исключением — value может быть закэшировано и возвращаться по operator*(). В ситуациях типа *it++ это может быть и приемлемо, однако в более сложных случаях вероятность ошибки очень велика.
Вопрос: Нужен ли реально постфиксный ++ в итераторах на потоках? Могут ли какие-либо алгоритмы использовать постфиксную запись (которая по-определению не более эффективна, чем префиксная) согласно стандарта?
Кроме того, такое кеширование значения (а не доступ напрямую к текущему потоку) требует конструктора по умолчанию для объектов итерации, тогда как прямой доступ требует только копирования...
Ваша точка зрения?
... << J 1.0 alpha 4 >>