Just to mention that it is used in some genetic algorithms (Non dominated Sorting Genetic Algorithm) to select potentially useful solutions: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.4257

There’s a reason why most folks use a combination of list + map to do an LRU queue — because you just can’t write an STL-compatible comparator that “just works right” in the manner you suggest.

For a “stable multiset”, I’ve rolled out some code that works but is nowhere near as polished as the boost/intrusive stuff — but it handles stability-under-equality (finally).

Dealing with equality is a pain in the butt: it basically means you need to handle extra cases at the binary-tree node-level operations. I’ll probably go back and see if I can hack something more boost-like.

Erik.

Also note that the gain is at best a factor, as both are O(n log n), some of which will be lost in using the new predicate. Is this (requiring to use sort rather than stable_sort) premature optimisation (or even pessimisation if adding the index costs)?

which makes me disinclined to use a library stable_sort if I can achieve the same effect with a faster sort algorithm just by providing a slightly more sophisticated predicate.

By providing a more sophisticated predicate, thus making me “total ordered”, the same result will be produced whether using library sort or stable_sort.

P.S. “stable” may have been in the vernacular, but when I took 6.036, The term C++ hadn’t even been coined yet, let alone stable_sort.

stable_sort grants that the relative order of the elements with equivalent values is preserved.

A technique to achieve stable_sort, with any sort algorithm, is that if two elements compare as equivalent through all of the provided predicate sort keys, then append a simple std::less comparison of the original index of each element. When doing a multi-field sort, the aggregation structure to represent what predicate and data field and width is primary key, what predicate and data field and width is the secondary key, what is tertiary, etc. is easy to extend by one more to refer to the fixed-width index/address of the elements.

A predicate invocation that would have been:

 if A.primary < B.primary
 else if B.primary < A.primary
 else if A.secondary < B.secondary
 else if B.secondary < A.secondary
 else if A.tertiary < B.tertiary
 else if B.tertiary < A.tertiary
 

gets extended one more level to

 else if A.origIndex < B.origIndex
 else if B.origIndex < A.origIndex

and there is no possibility of falling through past that.

Bingo

Duffy: order preserving sorts…are always total order.

I confess that I didn’t really understand the part in the “…”, but: stable_sort only requires a strict weak ordering, not a total order. So I’m really not sure what you’re driving at here.