7

In one of the C++ articles on STL, is being said that -

Since container adapters do not support iterators, hence they cannot be used with the STL algorithms.

But it did not explain as to why Container Adapters do not support iterators? Can anybody explain me the same?

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
XMarshall
  • 953
  • 3
  • 11
  • 23

2 Answers2

6

What's the point of a stack or a queue having an iterator? A stack is by definition something that you can only push and pop into... An iterator would destroy the whole purpose of these adapters

Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434
  • 2
    +1. To say the same another way, the purpose of a container iterator is to restrict the container API to the bare minimum operations required of the stack/queue/whatever abstraction. Iteration is not part of a bare minimum FIFO or LIFO. If you want an iterable queue, that behaves like a sequence for reading but can only be mutated like a queue, then either use the full container interface (and by choice don't call `insert`, only `push_back`), or else write your own container adaptor with a wider interface than `std::queue`. – Steve Jessop Jul 04 '11 at 09:25
  • So? The set of operations exposed is still a superset of input and output iterators. And plenty of STL algorithms work on those. E.g. `std::copy` could very well be used to push items on a stack. – MSalters Jul 04 '11 at 09:47
  • @MSalters: `std::copy` can be used to push items on a stack, with `back_inserter`. The stack doesn't need an iterator for that. Any operation which required an iterator *over the stack* would go beyond the minimal definition of LIFO stack. If iterators expose a strict superset of stack operations, that means it's inappropriate for a minimal stack interface to expose an iterator. – Steve Jessop Jul 04 '11 at 12:53
  • @Steve: doesn't `back_inserter` call `push_back`, a function that stack doesn't have? – Armen Tsirunyan Jul 04 '11 at 12:57
  • @Armen: sorry, quite right, I forgot that it's named `push` in `stack`, because of course it's moot whether the accessible end of a stack is the "front" or the "back". I guess you have to roll your own output iterator along the same lines - the general point though is that we're only accessing the end (both ends for `queue`), whereas an iterator by its nature accesses the parts of the sequence that `stack` and `queue` are specifically designed to hide. – Steve Jessop Jul 04 '11 at 13:00
  • So arguably it would be helpful for the standard library to provide a `push_iterator`, and maybe even a `pop_iterator` to go with `back_insert_iterator`. The latter would be an iterator over the `stack` or `queue`, but a destructive one, since (again by design) `stack` is *supposed* to prevent you visiting the later elements without removing their predecessors. If you don't want that, you don't want `stack`. – Steve Jessop Jul 04 '11 at 13:08
  • So, essentially, these adaptors could support iterators, even if they don't include them. In a sense, that fits in the C++ strategy of class design: don't add to a class what's equally well done outside that class. – MSalters Jul 05 '11 at 08:01
2

I would note that this is only an observation, not a rule.

That is, the Container Adapters provided in the STL do not support iteration, because they restrict the interface to conform to a specific model:

  • A stack may only be manipulated at one end
  • In a queue you may only push at one end and retrieve from the other

However, this is not a rule, and you may decide to create adapters that will support iteration.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722