Andrei Alexandrescu <[email protected]> wrote:
Instead of assuming that I'm simultaneously retard(ed) and stubborn
I'm sorry, that was not my intention.
I wrote BinaryHeap out of necessity. The necessity was to solve the
selection problem (see topN, topNIndex in std.algorithm) and to
implement n-way merge (see std.algorithm.nWayUnion, I think I'll rename
it to nWayMerge).
In all these cases, there was no necessity for defining a heap as a
container; instead, using it as a means to add structure over an
existing range were sufficient.
If I defined the heap as a container, there would be need for one extra
allocation and also extra indirections to ensure reference semantics. I
wanted to avoid all that.
Now this is exactly what I wanted! Thank you. Sorry we had to fight to
get there. :p
It's a good point. I agree it would make sense to define a binary heap
container in addition to a binary heap range. I'm only weary that they
don't have very clean means to reuse code, so we'll end up with some
unpleasant implementation internals. I guess I'll just have to do that.
I fear that this will also lead to confusion. "What? Two binheaps? What
do they need that for?" Basically, the binheap range is a heapifying
range, yes?
So to me, it seems to make sense to have std.range.heapify, and
std.container.binheap.
--
Simen
