hi phil,
Satisfactory. If possible, I think it would be good to provide the new heaps with interfaces as close as possible to the std:: heap, i.e. as algorithms (push, pop, etc.) over arbitrary containers or ranges, as well as the current containers. This would allow: (a) Existing code using std::push|pop_heap could be converted to use one of the alternative designs with just some search-and-replace; (b) Portions of a container could be managed as heaps, with other portions unordered, sorted, etc.; (c) Heaps over raw memory (e.g. memory-mapped files) would be possible. (I posted this suggestion in an email a few days ago but haven't had any replies. It is possible that there is something that I have overlooked that makes this impractical.)
it would only be reasonable for the container adaptors (d-ary and b-heaps). however i do not see a big advantage - some people discourage the use of b-heaps - the stl heap functions are usually d-ary heaps (iirc with an arity of 4) for the node-based heaps, this won't be possible ... mutability/stability will also require a specific layout so they cannot simply work on a memory regions like the stl functions ...
What is your evaluation of the documentation?
It needs some expansion, but it's on the right lines. It suffers, from too many, commas. A table indicating the features and complexity of those features for each heap would be useful at the start.
i am not a native speaker ... will try to improve thanks for your review, tim