0

Input iterators Output Iterators

  1. Swappable: The value pointed to by these iterators can be exchanged or swapped.

In these two links it's stated that the value pointed to by input iterators or output iterators can be exchanged or swapped. I'm not sure what they mean. In case of input iterators how would you change the value pointed to when you can't assign to them? In case of output iterators, how would you know what value to write when you can't read values?

Also it's stated that the output iterators cannot be compared for equality. Why?

StackExchange123
  • 1,871
  • 9
  • 24
  • 3
    that site is notoriously bad in teaching. I had a short glimpse and it was enough to see that much misinformation that I had to close the tab. – 463035818_is_not_an_ai Apr 13 '20 at 12:08
  • "So, the following two expressions are invalid if A and B are output iterators:" taking this literally (and it should be allowed to do that if they claim this content to be of any use), that statement is plain wrong. – 463035818_is_not_an_ai Apr 13 '20 at 12:11
  • @idclev463035818 Indeed. They are not "required" to support equality checks, but still may. (http://eel.is/c++draft/iterator.requirements#iterator.concept.output-1) – Asteroids With Wings Apr 13 '20 at 12:14
  • @AsteroidsWithWings I presume they tried to say that output iterators not necessarily are comparable via `==` and `!=` but thats not what is written there – 463035818_is_not_an_ai Apr 13 '20 at 12:16
  • 1
    conclusion: Don't try to learn from online tutorials. By the time you can tell the difference between the good, the bad, and the ugly, you don't need them anymore. – 463035818_is_not_an_ai Apr 13 '20 at 12:18

1 Answers1

2

It's not saying you can swap the values using those iterators, nor indeed swap the values at all. Or, if it is saying that, it is wrong.

Swappability is a requirement on the iterator type; this is just one of a few core rules for iterators ([iterator.iterators/2.1]).


As for comparing output iterators for equality, that statement is at least partially false. Output iterators are not required to support equality checks, but still may ([iterator.concept.output/1]). Where they can't, it's because there is no logical way to implement that. For example, off the top off my head, an ostream_iterator seems likely to fall into this category, because where does it "point"? How do you represent that?


So the website is, at best, misleading (at worst it is plain wrong), but that's why we do not learn C++ from random websites.

Asteroids With Wings
  • 17,071
  • 2
  • 21
  • 35
  • You misread the passage you quote. It's the iterators themselves that must be swappable, not the type it points to: "lvalues of type `X` are swappable" where `X` is the type of the iterator. – Igor Tandetnik Apr 13 '20 at 12:17
  • @AsteroidsWithWings Why would I want to read through an output iterator to compare it to another one? All I want is to know whether they point to the same location or not. I don't care about what they point to. – StackExchange123 Apr 13 '20 at 12:23
  • @StackExchange123 Haha I did it again. The same logic sort of applies though. What does "pointing to" really _mean_ for streams, for example? Pointers are not numbers, and iterators are not numbers, and this is an example of that. – Asteroids With Wings Apr 13 '20 at 12:24
  • @AsteroidsWithWings Don't iterators have a pointer or a reference to the object they're about to assign it a value? If not then how they assign values? If yes then why not comparing the addresses? – StackExchange123 Apr 13 '20 at 12:31
  • @StackExchange123 Only if they're that kind of iterator, and if having a pointer or reference makes sense for that kind of iterator. Not everything refers to some memory location. – Asteroids With Wings Apr 13 '20 at 12:35
  • @AsteroidsWithWings Why it won't always make sense for output iterators to be comparable for equality but always makes sense for input iterators? – StackExchange123 Apr 13 '20 at 12:41
  • @StackExchange123 It doesn't really, but input iterators need to be able to compare to "sentinel"s (end of input signalling). It's a bit of a design hack. The new "concept" for this doesn't require that (http://eel.is/c++draft/iterator.requirements#iterator.concept.input-1). I recommend not trying _too_ hard to look for logic here ;) – Asteroids With Wings Apr 13 '20 at 12:44