The logical argument is as follows
std::priority_queue
is a container adaptor; basic memory considerations make the back the preferred place for modifications (withpop_back()
andpush_back()
) for sequence containers such asstd::vector
.- the
priority_queue
primitives are based onstd::make_heap
(constructor),std::pop_heap
+container::pop_back
(priority_queue::pop
) and oncontainer::push_back
+std::push_heap
(priority_queue::push
) pop_heap
will take the front of the underlying storage, and put it at the back, restoring the heap invariant afterwards. The reverse goes forpush_heap
.- doing
sort_heap
on amax_heap
(with the max at the front initially) will repeatedly pop the front to the back and sort the range according toless
(which is the default comparison operator) - hence, the preferred implementation of a
max_heap
is to have the max element w.r.t.less
at the front, accessed throughpriority_queue::top
(underlyingcontainer::front
). - one can still debate whether it is intuitive that
priority_queue
with astd::less
comparator is representing amax_heap
. It could have been defined as amin_heap
by reversing the comparator’s arguments (but see the comment by @T.C. that with C++98 binders this is rather verbose) everywhere in the calls to the various heap functions. The one (for me) counter-intuitive result would have been thattop()
would then not have given the element with top priority