I know the reason is that those algorithms are specified to require sorted ranges as input, so unordered_set
will not work, but I wonder why those algorithms were not specified to understand unordered set containers.
In other words I understand that if I just give a range(2 iterators) to those algorithms they can not know how to efficiently look up elements in that unsorted range, but when I provide it a container that has member .contains()
it seems like they could do it(with terrible worst case complexity, but with same complexity as the regular set operations in happy cases).
My guess is that those algorithms already have gigantic list of requirements, and that work to handle this case(for example making sure they do not work on multiset containers) was not deemed worthy of effort for such rarely used algorithms.
But it is possible I am missing some other reason why this is not possible.
You mentioned the answer in "terrible worst case complexity".
using sorted ranges you can calculate the difference/intersection in linear complexity (
M+N
), but with unordered collections you have quadratic complexity, because even if the lookups in the unordered container are constant time (which are not a given), then you have to compare each element of the first container to each element of the second container, so you haveM*N
comparisons.Where
M
and 'N' are the sizes the containers.