Introduction

std::sort is not specified as "the quicksort function." The C++ standard library promises sorting behavior and performance characteristics, but it does not require one exact internal algorithm.

What the standard actually guarantees

When you call std::sort, you are asking the library to order a range accessed through random access iterators. The library must produce the correct ordering according to the comparator you provide, but the standard does not force it to use quicksort, mergesort, heapsort, or any other named algorithm.

That distinction matters because library vendors are free to choose the implementation that best satisfies the required complexity and practical performance goals. As a result, the honest answer to the title question is: not necessarily, and usually not as pure quicksort.

What most implementations do instead

Most mainstream standard libraries use a hybrid often described as introsort. It starts with quicksort-style partitioning because that is fast in the average case, but it does not stay there forever. If recursion gets too deep, the algorithm switches to heapsort to avoid quicksort's pathological behavior. Small partitions are often finished with insertion sort because that performs well on tiny ranges.

So people say "std::sort uses quicksort" because quicksort ideas are often part of the implementation. The more accurate statement is that many implementations use a quicksort-based hybrid rather than pure quicksort.

Here is a normal std::sort call:

1#include <algorithm>
2#include <iostream>
3#include <vector>
4
5int main() {
6    std::vector<int> values{9, 3, 7, 1, 8, 2, 6, 5, 4};
7
8    std::sort(values.begin(), values.end());
9
10    for (int value : values) {
11        std::cout << value << ' ';
12    }
13
14    std::cout << '\n';
15}

The code does not reveal the underlying algorithm, and that is intentional. The abstraction is part of the interface.

Why implementation details should not drive your API choice

In day-to-day C++ code, you should choose std::sort because you need a fast in-place sort for random access iterators, not because you want a particular textbook algorithm. If you need stability, then std::stable_sort is the better tool. If you need a partial ordering, std::nth_element or std::partial_sort may be more appropriate.

A second example shows a custom comparator:

1#include <algorithm>
2#include <iostream>
3#include <string>
4#include <vector>
5
6int main() {
7    std::vector<std::string> words{"pear", "banana", "fig", "apple"};
8
9    std::sort(words.begin(), words.end(),
10              [](const std::string& a, const std::string& b) {
11                  if (a.size() != b.size()) {
12                      return a.size() < b.size();
13                  }
14                  return a < b;
15              });
16
17    for (const auto& word : words) {
18        std::cout << word << '\n';
19    }
20}

The important contract here is not the sorting algorithm. It is that the comparator defines a valid strict ordering. If the comparator is inconsistent, any sort algorithm may behave unpredictably.

Performance expectations in practice

std::sort is usually the right default because standard library authors spend a lot of effort optimizing it for real workloads. It is typically in-place apart from stack usage, fast on general-purpose data, and battle-tested across platforms.

That said, benchmarking still matters. Sorting strings, large structs, or data with expensive comparisons can shift where the time goes. In many programs the comparator and memory access pattern matter more than the exact partitioning strategy used internally.

Common Pitfalls

• Assuming std::sort is stable. Equal elements may change relative order. Use std::stable_sort when that property matters.
• Writing a comparator that violates strict weak ordering. That can produce undefined or surprising results.
• Using std::sort on containers without random access iterators. For example, linked lists need their own member sort.
• Arguing from implementation internals instead of the standard contract. Different libraries can choose different strategies.
• Expecting pure quicksort worst-case behavior. Modern libraries are designed to avoid that weakness.

Summary

• 'std::sort is not specified as pure quicksort.'
• Most implementations use a hybrid such as introsort, which includes quicksort ideas but is more robust.
• The standard guarantees correct ordering and performance properties, not one named algorithm.
• Choose std::sort for fast general-purpose sorting of random access ranges.
• If you need stability or a different ordering task, use the algorithm that matches that requirement instead.