A dispenser is called that way because of the image of a vending machine (a dispenser) of a rather primitive nature, in which there is only one button. If you press the button and the dispenser is not empty, you get one of its items in the exit tray at the bottom, but you do not choose that item: the machine does. There is also an input slot at the top, into which you may deposit new items; but you have no control over the order in which successive button press operations will retrieve these items.
The deferred class DISPENSER provides the facilities which will be shared by all specialized classes. In fact, the interface of all dispenser classes is nearly identical, with the exception of a few extra possibilities offered by priority queues. Many kinds of dispenser are possible, each defined by the relation that the machine defines between the order in which items are inserted and the order in which they are returned. The Base libraries support three important categories - stacks, queues, and priority queues:
Stacks - dispensers with a LIFO retrieval policy - are a ubiquitous structure in software
development. Their most famous application is to parsing (syntactic analysis), but many
other types of systems use one or more stacks.
Class STACK describes
general stacks, without commitment to a representation. This is a deferred class which
may not be directly instantiated. The fundamental operations are
put (add
an element at end of queue),
item (retrieve
the oldest element, non-destructively),
remove
(remove the oldest element),
is_empty
(test for empty queue).
Three effective heirs are provided:
Class QUEUE describes general queues, without commitment to a representation. This is a deferred class which may not be directly instantiated. Three non-deferred heirs are also provided, distinguished by the same properties as their stack counterparts:
In a priority queue, each item has an associated priority value, and there is an order relation on these values. The item returned by item or removed by remove is the element with the highest priority. The most general class is PRIORITY_QUEUE , which is deferred. Two effective variants are provided:
Because it must be possible to compare priorities, the type of the items must conform to PART_COMPARABLE. Constrained genericity ensures this; all the priority queue classes have a formal generic parameter constrained by PART_COMPARABLE.