Priority queues are queues of objects, that are ordered by their priority.
They support the operations of adding nodes to the data structure, accessing
the top element (the element with the highest priority), and removing the
top element.

Note

boost.heap implements priority queues as max-heaps to
be consistent with the STL heap functions. This is in contrast to the typical
textbook design, which uses min-heaps.

classiteratable_heap_interface{public:// typestypedefunspecifiediterator;typedefunspecifiedconst_iterator;typedefunspecifiedordered_iterator;// public member functionsiteratorbegin(void)const;iteratorend(void)const;ordered_iteratorordered_begin(void)const;ordered_iteratorordered_end(void)const;};

Priority queues provide iterators, that can be used to traverse their elements.
All heap iterators are const_iterators, that means they cannot be used to
modify the values, because changing the value of a heap node may corrupt
the heap order. Details about modifying heap nodes are described in the section
about the mutability interface.

Iterators do not visit heap elements in any specific order. Unless otherwise
noted, all non-const heap member functions invalidate iterators, while all
const member functions preserve the iterator validity.

Note

Some implementations require iterators, that contain a set of elements,
that are discovered, but not visited. Therefore copying iterators can be inefficient
and should be avoided.

Except for boost::heap::priority_queue
all boost.heap data structures support ordered iterators,
which visit all elements of the heap in heap-order. The implementation
of these ordered_iterators requires some internal bookkeeping,
so iterating the a heap in heap order has an amortized complexity of O(N*log(N)).

The data structures of boost.heap can be compared with
standard comparison operators. The comparison is performed by comparing two
heaps element by element using value_compare.

Note

Depending on the heap type, this operation can be rather expensive, because
both data structures need to be traversed in heap order. On heaps without
ordered iterators, the heap needs to be copied internally. The typical
complexity is O(n log(n)).

boost.heap provides a heap_merge()
algorithm that is can be used to merge different kinds of heaps. Using this
algorithm, all boost.heap data structures can be merged,
although some cannot be merged efficiently.

Some priority queues of boost.heap are mutable, that means
the priority of their elements can be changed. To achieve mutability, boost.heap
introduces the concept of handles, which
can be used to access the internal nodes of the priority queue in order to
change its value and to restore the heap order.

There are two different APIs to support mutability. The first family of functions
provides update functionality by changing the current element by assigning
a new value. The second family of functions can be used to fix the heap data
structure after an element has been changed directly via a handle. While
this provides the user with a means to modify the priority of queue elements
without the need to change their non-priority part, this needs to be handled
with care. The heap needs to be fixed up immediately after the priority of
the element has been changed.

Beside an update function, two additional functions increase
and decrease are provided, that are generally more efficient
than the generic update function. However the user has
do ensure, that the priority of an element is changed to the right direction.

// PriorityQueue is expected to be a max-heap of integer valuestemplate<typenamePriorityQueue>voidmutable_fixup_interface(void){PriorityQueuepq;typedeftypenamePriorityQueue::handle_typehandle_t;handle_tt3=pq.push(3);handle_tt5=pq.push(5);handle_tt1=pq.push(1);*t3=4;pq.update(t3);*t5=7;pq.increase(t5);*t1=0;pq.decrease(t1);cout<<"Priority Queue: update with fixup"<<endl;while(!pq.empty()){cout<<pq.top()<<" ";// 7, 4, 0pq.pop();}cout<<endl;}

Iterators can be coverted to handles using the static member function s_handle_from_iterator.
However most implementations of update invalidate all
iterators. The most notable exception is the fibonacci
heap, providing a lazy update function, that just invalidates
the iterators, that are related to this handle.

Warning

After changing the priority via a handle, the heap needs to be fixed by
calling one of the update functions. Otherwise the priority queue structure
may be corrupted!

A priority queue is `stable', if elements with the same priority are popped
from the heap, in the same order as they are inserted. The data structures
provided by boost.heap, can be configured to be stable
at compile time using the boost::heap::stable
policy. Two notions of stability are supported. If a heap is configured with
no stability, the order of nodes of the
same priority is undefined, if it is configured as stable,
nodes of the same priority are ordered by their insertion time.

Stability is achieved by associating an integer version count with each value
in order to distinguish values with the same node. The type of this version
count defaults to boost::uintmax_t, which is at least
64bit on most systems. However it can be configured to use a different type
using the boost::heap::stability_counter_type
template argument.

Warning

The stability counter is prone to integer overflows. If an overflow occurs
during a push() call, the operation will fail and an
exception is thrown. Later push() call will succeed,
but the stable heap order will be compromised. However an integer overflow
at 64bit is very unlikely: if an application would issue one push()
operation per microsecond, the value will overflow in more than 500000
years.