Introduction

The C++ standard library requires a strict weak ordering because algorithms such as std::sort and containers such as std::set need comparisons to behave consistently. If the comparator contradicts itself, the library cannot build a stable ordering model, and the algorithm's assumptions stop being valid.

What Strict Weak Ordering Means

A comparator such as comp(a, b) should behave like a sensible "comes before" relation. In practice, that means:

• 'comp(a, a) must be false'
• if comp(a, b) is true, then comp(b, a) must be false
• if comp(a, b) and comp(b, c) are true, then comp(a, c) must also be true

It also means that the "equivalent" cases behave consistently. If a is neither before b nor after b, and the same is true between b and c, then the library must be able to treat those relationships coherently.

That is what lets the standard library reason about sorted ranges and equivalence classes.

Why std::sort Needs It

Sorting is not just repeated pairwise swapping. std::sort assumes the comparator describes a stable ordering relation over the whole range.

A correct comparator:

1#include <algorithm>
2#include <vector>
3
4int main() {
5    std::vector<int> values{4, 1, 3, 2};
6    std::sort(values.begin(), values.end(),
7              [](int a, int b) { return a < b; });
8}

A broken comparator:

1#include <algorithm>
2#include <vector>
3
4int main() {
5    std::vector<int> values{4, 1, 3, 2};
6    std::sort(values.begin(), values.end(),
7              [](int a, int b) { return a <= b; });
8}

The second comparator violates irreflexivity because comp(a, a) is true. That breaks the assumptions the algorithm uses to partition and reorder elements.

Once the comparator stops describing a valid ordering, the library can no longer guarantee meaningful behavior.

Why Associative Containers Need It

Containers such as std::set and std::map also rely on ordering to decide where elements belong and whether two keys should be treated as equivalent.

For a std::set, equivalence is defined by the comparator, not by operator==. Two values are considered equivalent if neither is less than the other under the ordering relation.

That design only works if the comparator is consistent. Otherwise the container cannot reliably maintain its internal tree structure or determine uniqueness correctly.

Equivalence Classes Are the Hidden Reason

Strict weak ordering is weaker than a total ordering because distinct elements may still be equivalent under the comparator. For example, you might sort people by age only, so two people of the same age are equivalent from the comparator's point of view.

That is allowed. What is not allowed is having those equivalence relationships behave inconsistently across comparisons.

The library does not need every pair of elements to be different. It needs the grouping and ordering logic to remain coherent.

Common Pitfalls

The biggest mistake is writing a comparator that uses <= instead of <. That almost always breaks the required ordering rules immediately.

Another common issue is writing a comparator that depends on mutable external state or random behavior. If the answer to "is a before b?" changes during the algorithm, the ordering is no longer reliable.

It is also easy to confuse "works on my test input" with correctness. A bad comparator can appear to work on small inputs while still violating the standard library's contract.

Summary

• The standard library requires strict weak ordering so sorting and ordered containers can reason about comparisons consistently.
• A valid comparator must be irreflexive, asymmetric, and transitive in the right way.
• 'std::sort, std::set, and std::map all depend on these guarantees.'
• Using <= as a comparator is a classic bug because it violates the ordering rules.
• The requirement is really about making equivalence classes and ordering behavior coherent for generic algorithms.