(3 2 1) -> (2 3 1) -> (2 1 3) -> (1 2 3) (3 passes, 3 swaps)
Compare: (1 3 2) - > (1 2 3) (2 passes, 1 swap)
However, relying on stability if it is not specified is a bad thing.
When possible, it would of course be best to use stdlib functionality, which would implicitly be cross-platform. Writing it yourself, or pulling in third-party libs to do it ranks way below stdlib, although I can't agree with myself whether doing so is better or worse than using OS-specific standard frameworks. Regardless, it is out of scope in this example.
Do you really think that when you sort a column in Excel, it puts the whole thing into a CFMutableArray and asks CoreFoundation to sort that?
Using CoreFoundation in such code is entirely sensible. Generalizing a sort for something like this would be a waste of time with no gains (as long as the functionality is used correctly, like not assuming a non-specified sort to be stable).
However, for the actual business logic, the hierarchy would be:
stdlib > large third-party cross-platform lib > small third party cross-platform lib ≈ homegrown implementation.In fact friends don't even let enemies use bubble sort, if they have an ounce of humanity.
Edit to actually answer the question: I wonder if it's something to do with some specific dataset having to be sorted in a particular way? i.e. where you'd normally use a stable sort, but the code accidentally depends on a specific unstable sort.
1. Excel needs stable sort but OSX sort is unstable.
2. Performance deoptimisation to make Excel perform worse.
2 occurred to me too, but surely that’s too cynical. It would make Macs look bad more than Excel itself.
Maybe it’s a bit of both. They needed a fix for 1, but they didn’t care about Excel performance at all so someone just spent 20 seconds doing a quick bodge job.
Mac Outlook on a recent MBP is noticeably slower (usability impact) than a similar version of Outlook on my Windows VM on the same machine against the same account (30k items, 5GB-ish)
There are dual-pivot quicksort, smooth sort (in-place, based on Leonardo numbers and takes O(n) time to process a presorted array and O(n log n) in the worst case, and achieves nearly-linear performance on many nearly-sorted inputs), TimSort (that's stable as plus).
Morealso changing stable to unstable sort is usually a very bad move.
The comparator here is "used" or "empty", where "used" is either > or < "empty".
That said, bubble sort is only n^2 and computers are fast. The real solution was that defrag was an alternative to crashing, so it didn't matter how long it took. Calling it meant a bug report needed to be filed.
So you wrote a non-compacting(copy)/generation garbage collector that used bubble sort?