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.

More recent revisions of XML Schema xsd:double and xsd:float have come off that original stance somewhat, instead using the following phrases:

Positive infinity is greater than all other non-NaN values. NaN equals itself but is ·incomparable· with (neither greater than nor less than) any other value in the ·value space·. This datatype differs from that of [IEEE 754-1985] in that there is only one NaN and only one zero. This makes the equality and ordering of values in the data space differ from that of [IEEE 754-1985] only in that for schema purposes NaN = NaN.

Still it does tend to require a dedicated clause in code to get sorting compatible with this, out of IEEE floating point. One allowance that should be recognized, the XML schema governs textual representations of numbers, not the binary representations. To say that NaN = NaN, for XML means \116\141\116 equals \116\141\116, not that the 32bit or 64bit binary patterns which are NaN in IEEE floating point all equal each other. If you use XML in your programming domain, however, for the XML floating point to sort differently from the binary floating point, is usually undesirable.