Comment by derriz
Unless you know about the internal implementation of std::map, then abusing the ordering function (which is expected be a total order according to the std::map documentation - i.e. capable of comparing any two elements of the key space) to throw exception when the API for std::map is used in a way you want to block - is not a robust solution. This will probably work but there’s nothing that constrains std::map to be implemented as a RB tree.
Nor is it intuitive - given it relies on understanding how balanced trees are typically implemented.
An “optimized” implementation of std::map should be entitled, for example, to cache results of previous comparisons and exploit the transitive rule for total orders to avoid unnecessarily performing comparisons. Then this solution breaks.
I know whining about downvotes is frowned upon here but I’m surprised to having lost karma here. I’m making what I believe is a good faith argument and am happy to debate my position.
> internal implementation of std::map > abusing the ordering function
That's the thing about C++. It's not abuse - any strict weak ordering is valid. You are follow the rules and it's guaranteed mathematically to produce correct results.
> capable of comparing any two elements of the key space
You get to define the domain of keys which is almost always a restriction of the possible bits of the key. For example, you can use floats as keys even though nan would break.
> Nor is it intuitive
Intuitive too often means "I haven't seen it before" which is a bias to not learn new approaches of programming. All sufficiently technical knowledge is unintuitive.
- it relies on understanding how balanced trees are typically implemented.
No it doesn't. It's documented API.
> exploit the transitive rule for total orders to avoid unnecessarily performing comparisons
Yes, the comparison must satisfy transitivity. This doesn't violate that.
> I know whining about downvotes is frowned upon here
I downvote low-quality, not to disagree (I did not downvote).