C++ Standard Template Library

Standard Template Library
Ilio Catallo - info@iliocatallo.it

Outline
• Introduc*on
• Ideals and concepts
• Generic programming
• Bibliography

The Standard Template Library
The C++ Standard Library includes a set of algorithms and data
structures that were originally part of a third-party library, called
the Standard Template Library (STL)

The Standard Template
Library
The Standard Template Library was
invented by Alexander Stepanov in 1994
circa, and later included in the C++
Standard Library

Library
The STL is the outcome of two decades of
Stepanov's eﬀort in delinea8ng the
fundamental principles of programming

Library
Before turning to C++, Stepanov
unsuccessfully tried implemen9ng the STL
using languages such as Scheme and Ada

An approach to computa-on
"The STL is unlike any other library you have seen before."
(S. T. Lavavej)

An approach to computa-on
"People look at STL and think it's a nice container and algorithm library.
It is not, it is a diﬀerent way of thinking about code."
(S. Parent)

What makes the STL so special?

Storing and manipula/ng objects
Consider the problem of storing objects in containers and wri6ng
algorithms to manipulate such objects

We want to be able to store objects of a variety of types in a
variety of containers and to apply a variety of algorithms

Furthermore, we want the use of these objects, containers, and
algorithms to be:
• Sta%cally type safe
• As fast possible
• As compact as possible
• Not verbose and readable

"Achieving all of this simultaneously isn't easy. In fact, I spent about 10
years unsuccessfully looking for a solu>on to this puzzle."
(B. Stroustrup)

List inser)on
In order to appreciate this, let us consider the problem of inser5ng
an arbitrary long sequence of progressive numbers into a list

List inser)on
We will see how to solve this problem using STL and Glib1
1
Glib is a general-purpose C library associated with the GNOME desktop environment. For more informaBon about
GLib, see hEps://developer.gnome.org/glib/stable/

STL: inser+on
std::list<int> l;
for (int i = 0; i < 10; i++) l.push_back(i);

Glib: inser+on
GList* list = NULL;
int* data_ptr;
for (int i = 0; i < 10; i++) {
data_ptr = g_new(int, 1);
*data_ptr = i;
list = g_list_append(list, (void*) data_ptr);
}

The N·M problem
Before the STL, all the available general computa8on libraries
suﬀered from the N·M problem

The N·M problem
If you have N containers and M algorithms, you need N·M diﬀerent
implementa;ons in order to provide each algorithm for each
possible container

Glib: ﬁnding in a doubly-linked list
GList* list = ...;
GList* tmp;
int* data_ptr;
*data_ptr = 7;
tmp = g_list_find(list, (void*) data_ptr);

Glib: ﬁnding in a singly-linked list
GSList* list = ...;
GSList* tmp;
int* data_ptr;
*data_ptr = 7;
tmp = g_slist_find(list, (void*) data_ptr);

The STL solu+on
The STL solu+on is based on parameterizing containers with their
element types and on completely separa-ng the algorithms from
the containers

STL: ﬁnding in a doubly-linked list
std::list<int> l = {1, 10, 8, 7};
auto p = std::find(l.begin(), l.end(), 7);

STL: ﬁnding in a singly-linked list
std::forward_list<int> l = {1, 10, 8, 7};
auto p = std::find(l.begin(), l.end(), 7);

The STL is extensible
Since containers and algorithms are independent, introducing a
new container does not require reimplemen6ng all the available
algorithms

The STL is extensible
All available algorithms will simply work with the new container

The STL components
The STL is composed of three main components, namely,
algorithms, iterators and containers
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ │ │ │ │ │
│ │ use │ │ expose │ │
│ Algorithms │────────▶│ Iterators │ ──────────│ Containers │
│ │ │ │ │ │
│ │ │ │ │ │
└───────────────────┘ └───────────────────┘ └───────────────────┘

The STL components
Moreover, func%on objects are used to customize both algorithms
and containers
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ │ │ │ │ │
│ │ use │ │ expose │ │
│ Algorithms │─────────▶│ Iterators │ ─────────│ Containers │
│ │ │ │ │ │
│ │ │ │ │ │
└───────────────────┘ └───────────────────┘ └───────────────────┘
▲ ▲
│ │
│ │
│ ┌───────────────────┐ │
│ │ │ │
│ customize │ │ customize │
└────────────────────│ Function objects │─────────────────────┘
│ │
│ │
└───────────────────┘

The swap func)on
We extensively discussed the proper.es of the swap func.on

swap alterna(ves
At ﬁrst, we wrote several alterna*ves of the swap func0on, each
of which tailored for a speciﬁc built-in type
void swap(int& x, int& y) {
int tmp = x;
x = y;
y = tmp;
}

swap alterna(ves
void swap(double& x, double& y) {
double tmp = x;
x = y;
y = tmp;
}

swap alterna(ves
void swap(char& x, char& y) {
char tmp = x;
x = y;
y = tmp;
}

swap for built-in types
Later, we no+ced that we can devise a uniform implementa.on of
swap for any built-in type T
// T is a built-in type
void swap(T& x, T& y) {
T tmp = x;
x = y;
y = tmp;
}

swap for semi-regular types
Ul#mately, we observed that the very same implementa#on is s#ll
valid for any copy-construc+ble and assignable type
// T is copy-constructible and assignable
T tmp = x;
x = y;
y = tmp;
}

swap for semi-regular types
That is, the same implementa.on is valid for any semi-regular type
// T is semi-regular
T tmp = x;
x = y;
y = tmp;
}

Language limita,ons
Unsurprisingly, the following code does not compile
T tmp = x;
x = y;
y = tmp;
}

Language limita,ons
Unsurprisingly, the following code does not compile
// void swap(T& x, T& y) {
// ^
// error: 'T' was not declared in this scope

Language limita,ons
This is because the compiler requires func4on parameters to be
exis%ng types
T tmp = x;
x = y;
y = tmp;
}

Language limita,ons
Apparently, the language is limi&ng us in harnessing the underlying
regularity we were able to no5ce
T tmp = x;
x = y;
y = tmp;
}

Func%on templates
To solve this, we will turn swap into a func%on template

Func%on templates
A func'on template deﬁnes a family of func,ons, rather than a
single func'on

swap as a func(on template
This allows us to deﬁne at once all the alterna1ve versions of swap
function template: swap(T&, T&)
┌────────────────────────────────────────────────────┐
│ │
│ • swap(double&, double&) │
│ │
│ │
│ • swap(int&, int&) │
│ │
│ │
│ • swap(char&, char&) │
│ │
│ • swap(float&, float&) │
│ │
│ │
│ │
│ • swap(vector_int&, vector_int&) │
│ │
└────────────────────────────────────────────────────┘

swap as a func(on template
The deﬁni)on of swap as a func)on template is as follows:
template <typename T> // T is semi-regular
T tmp = x;
x = y;
y = tmp;
}

Template instan,a,on
The func. template generates as many actual func1ons as needed
T = double → swap(double&, double&)

T = int → swap(int&, int&)

T = char → swap(char&, char&)

Func%on templates are instan%ated at compile-)me
template <typename T>
void swap(T& x, T& y) { ... }
int main() {
float f1 = 3.4, f2 = 7.3;
char c1 = 'a', c2 = 'b';
swap(f1, f2);
swap(c1, c2);
}

Func%on templates are instan%ated at compile-)me
void swap(float& x, float& y) { ... }
void swap(char& x, char& y) { ... }
int main() {
float f1 = 3.4, f2 = 7.3;
char c1 = 'a', c2 = 'b';
swap(f1, f2);
swap(c1, c2);
}

std::swap
In fact, we derived the deﬁni1on of std::swap as of C++03
template <typename T> // T is semi-regular
T tmp = x;
x = y;
y = tmp;
}

The min_element algorithm
In a previous lecture, we devised an algorithm for ﬁnding the
minimum element of an integer array

int* min_element(int* first, int* last) {
if (first == last) return last;
int* min = first;
++first;
while (first != last) {
if (*first < *min) min = first;
++first;
}
return min;
}

It is immediate to see that the procedure does not depend on the
elements being integers
int* min_element(int* first, int* last) { ... }

double* min_element(double* first, double* last) { ... }

char* min_element(char* first, char* last) { ... }

Hence, we can write min_element as a func%on template
template <typename I>
I min_element(I first, I last) { ... }

min_element as a func(on template
I min_element(I first, I last) {
I min = first;
++first;
++first;
}
return min;
}

Element type independence
We can now invoke min_element regardless of the element type

Using min_element
int main() {
double ds[] = {7.1, 2.3, 5.6, 9.0};
char cs[] = {'a', 'b', 'c'};
double* d = min_element(ds, ds + 4);
char* c = min_element(cs, cs + 3);
}

Using min_element
I is derived to be double* when passing an array of m elements of
type double

Using min_element
I is derived to be char* when passing an array of m elements of
type char

Can we use min_element on linked lists?

Finding the minimum
The algorithm for ﬁnding the minimum is independent of the way
we store elements in memory
┌───┬───┬───┬───┬ ─ ┐
xs: │ 1 │ 7 │13 │ 5 │
└───┴───┴───┴───┴ ─ ┘
┌───┐ ┌───┐ ┌───┐ ┌───┐
xs: │ 1 ├──┤ 7 ├──┤13 ├──┤ 5 │──▶ *
└───┘ └───┘ └───┘ └───┘

Finding the minimum
Because of this, we should be able to apply min_element on
linked lists as well
┌───┬───┬───┬───┬ ─ ┐
xs: │ 1 │ 7 │13 │ 5 │
└───┴───┴───┴───┴ ─ ┘
┌───┐ ┌───┐ ┌───┐ ┌───┐
xs: │ 1 ├──┤ 7 ├──┤13 ├──┤ 5 │──▶ *
└───┘ └───┘ └───┘ └───┘

Requirements on I
For min_element to work, we need some proper/es to hold for I
I min = first;
++first;
++first;
}
return min;
}

Requirements on I
Namely, we require I to be:
• Equality & inequality comparable
• Copy construc6ble & assignable
• Incrementable

Passing a pointer
For arrays, I is derived to be a pointer

Passing a pointer
Since pointers sa-sfy the requirements we iden-ﬁed, the algorithm
works

Linked lists
However, intrusive linked lists are usually implemented as
struct node {
int value;
node* next;
};

Linked lists
Therefore, we need to subs0tute pointers with a user-deﬁned type
that s0ll meets the requirements for I

Iterators
We refer to such user-deﬁned types as iterators
class list_iterator {
...
};

Linked list iterator
Namely, we will write a class named list_iterator to be used
in conjunc5on with the node class
...
};

list_iterator representa)on
public:
...
private:
???
};

list_iterator representa)on
public:
...
private:
node* curr;
};

list_iterator constructor
public:
list_iterator(???): ??? { ??? }
private:
node* curr;
};

list_iterator constructor
public:
list_iterator(node* curr): curr(curr) {}
private:
node* curr;
};

list_iterator default constructor
public:
list_iterator(): curr(nullptr) {}
private:
node* curr;
};

Dereference overload
public:
??? operator*() ??? { ??? }
private:
node* curr;
};

Dereference overload
public:
int& operator*() const { return curr->value; }
private:
node* curr;
};

Dereference constness
Note that operator* is always const, even for non-const
iterators

Constness only means that the iterator cannot be later modiﬁed so
as to point to a diﬀerent posi5on in the data structure
list_iterator const it1 = ...;
it1 = it2; // it1 cannot be re-assigned so as to point to a different location

Nevertheless, it is perfectly valid to modify the data pointed to by a
constant iterator
list_iterator const it1 = ...;
*it1 = 10;

Recall that we are trying to mimic pointers, and this is perfectly
aligned with the way pointers behave:
int a = 10, b = 7;
int* const p = &a;
p = &b; // error: p is a constant pointer
*p = 5; // legit: a is now 5

Preﬁx increment overload
public:
??? operator++() { ??? }
private:
node* curr;
};

Preﬁx increment overload
public:
list_iterator& operator++() { curr = curr->next;
return *this; }
private:
node* curr;
};

Equality overload
public:
return *this; }
bool operator==(list_iterator& y) const { ??? }
private:
node* curr;
};

Equality overload
public:
return *this; }
bool operator==(list_iterator& y) const { return curr == y.curr; }
private:
node* curr;
};

Inequality overload
public:
return *this; }
bool operator==(list_iterator& y) const { return curr == y.curr; }
bool operator!=(list_iterator& y) const { return !(*this == y); }
private:
node* curr;
};

list_iterator
list_iterator supports all opera+ons required by
min_element

min_element
void print_min(node* head) {
list_iterator first(head);
list_iterator last;
list_iterator m = min_element(first, last);
if (m != last)
std::cout << "the min is " << *m;
}

Algorithms vs. containers
Note that min_element is completely unaware of the existence
of any container

As a ma&er of fact, min_element works as long as we provide a
type that meets the requirements for I

"The reason that data structures and algorithms can work together
seamlessly is... that they do not know anything about each other."
(A. Stepanov)

Iterators delimit sequences
An iterator allows abstrac/ng an arbitrary container as a sequence
of elements
┌───┬───┬───┬ ─ ┐
│ 7 │12 │ 3 │
└───┴───┴───┴ ─▲┘
│
│
│
past-the-end
element

Iterators delimit sequences
This is true regardless of the fact that elements may in fact not be
con4guously allocated in memory (as with linked lists)
3rd past-the-end 1st 2nd
elem. elem. elem. elem.
──────▶ ───────▶ ───────▶ ───────▶
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
... │ │ │///│///│ │ │///│///│ │ │ │ │///│///│ │ │///│///│ ...
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
──▶
1 byte

list_iterator vs. pointers
Note that list_iterator does not support all pointer
opera*ons
...
};

list_iterator vs. pointers
For instance, we cannot decrement a list_iterator
list_iterator it;
--it; // compile-time error;

Forward iterators
We refer to iterators such as list_iterator as forward
iterators

Random access iterators
A pointer – on the other hand – models a random access iterator,
which is the most feature-rich iterator possible

Iterator hierarchy
┌──────────────────────────────┐
│ Iterator │
└──────────────────────────────┘
▲
│
┌──────────────────────────────┐
│ Input Iterator │
└──────────────────────────────┘
▲
│
┌──────────────────────────────┐
│ Forward Iterator │
└──────────────────────────────┘
▲
│
┌──────────────────────────────┐
│ Bidirectional Iterator │
└──────────────────────────────┘
▲
│
┌──────────────────────────────┐
│ Random Access Iterator │
└──────────────────────────────┘

Requirements on I
Therefore, we can now reﬁne the requirements on I

Requirements on I
Namely, we require I to be a forward iterator

Requirements on I
Namely, we require I to be a forward iterator
template <typename I> // I is a forward iterator

Requirements on I
Moreover, the type resul/ng from dereferencing the forward
iterator (i.e., its value type) should model a totally ordered type
// I is a forward iterator
// I's value type is a totally ordered type

Top-down vs. bo-om-up
No#ce that we could not iden#fy the requirements without looking
at the implementa)on

This is to say that – some-mes – we cannot determine the
interface in a top-down fashion

Some%mes, we need to look at the implementa%on to determine
the interface

vector_int
During previous classes, we were able to incrementally write a
simpliﬁed version of std::vector called vector_int
class vector_int {
...
};

vector_int
class vector_int {
public:
vector_int(): sz(0), elem(nullptr) {}
vector_int(std::size_t sz): sz(sz), elem(new int[sz]) {...}
vector_int(vector_int const& v): sz(v.sz), elem(new int[v.sz]) {...}
~vector_int() {...}
std::size_t size() const {...}
int operator[](std::size_t i) const {...}
int& operator[](std::size_t i) {...}
vector_int& operator=(vector_int const& v) {...}
bool operator<(vector_int const& v) const {...}
// definitions for !=, <, >=, <=
private:
std::size_t sz;
int* elem;
};

vector_int vs. algorithms
Unfortunately, vector_int cannot be used with any of the
algorithms we previously wrote (e.g., copy and min_element)

Algorithms expect iterators
As we just saw, algorithms that operate on a sequence expects a
pair of iterators, rather than the container per se

vector_int vs. algorithms
To solve this, vector_int should be able to expose its own
iterators

begin() and end()
Namely, vector_int should provide two member func8ons
named begin() and end()2
2
And possible constant variants cbegin() and cend()

begin() and end()
begin() and end() should return an iterator to the ﬁrst and to
the past-the-end element, respec2vely
┌───┬───┬───┬ ─ ┐
│ 7 │12 │ 3 │
└───┴───┴───┴ ─▲┘
│
│
│
past-the-end
element

begin() and end()
Let us add begin() and end() to vector_int
class vector_int {
public:
...
??? begin() { ??? }
??? end() { ??? }
private:
std::size_t sz;
int* elem;
};

begin() and end()
Let us add begin() and end() to vector_int
class vector_int {
public:
...
int* begin() { return elem; }
int* end() { return elem + sz; }
private:
std::size_t sz;
int* elem;
};

Const begin() and end()
class vector_int {
public:
...
int* begin() { return elem; }
int* end() { return elem + sz; }
int const* begin() const { return elem; }
int const* end() const { return elem + sz; }
private:
std::size_t sz;
int* elem;
};

vector_int and min_element
void print_min(vector_int v) {
int* first = v.begin();
int* last = v.end();
int* m = min_element(first, last);
if (m != last)
}

Although the code works, we s1ll have a issue
void print_min(vector_int v) {
int* m = min_element(first, last);
if (m != last)
}

More precisely, we are revealing too much about the type of the
iterator

Users of vector_int should not be concerned with the fact that
iterators are either pointers or user-deﬁned types

Member type aliases
Thus, we will hide the actual type of the iterator through the use of
member type aliases (or simply member types)

Member type aliases
Member types are type aliases that are deﬁned within the scope of
a class

Type aliases
int main() {
using integer = int;
integer a = 5; // the same as: int a = 5;
}

Member type aliases
class X {
public:
using integer = int;
};
int main() {
// the same as: int a = 5;
X::integer a = 5;
}

Iterator member types
Type aliases for iterators and const iterators are required to be
called, resp., iterator and const_iterator
class vector_int {
public
using iterator = ???
using const_iterator = ???
...
};

Type aliases for iterators and const iterators are required to be
called, resp., iterator and const_iterator
class vector_int {
public
using iterator = int*;
using const_iterator = int const*;
...
};

We consequently change the return type of begin() and end()
class vector_int {
public
...
};

class vector_int {
public:
...
iterator begin() { return elem; }
iterator end() { return elem + sz; }
const_iterator begin() const { return elem; }
const_iterator end() const { return elem + sz; }
private:
std::size_t sz;
int* elem;
};

Random access iterator
No#ce that vector_int::iterator is a random access iterator
vector_int::iterator first = v.begin();
first = first + 2; // random access

std::vector's iterator type
Similarly, given a value of type std::vector<T>, the related
iterator type is std::vector<T>::iterator
std::vector<int> v = {7, 10, 5, 8};
std::vector<int>::iterator first = v.begin();
std::vector<int>::iterator last = v.end();

vector_double
It is immediate to see that the if we had to write vector_double,
its implementa3on would not diﬀer from that of vector_int
class vector_double {
public:
...
private:
std::size_t sz;
double* elem;
};

Class template
As with algorithms, we can express such a similarity by turning
vector_int in a class template

vector_int as a class template
As a class template, we can parameterize vector_int over its
element type
class vector_int {
...
};

vector_int → vector
Since our container is not limited to int elements anymore, we
rename it vector
class vector {
...
};

vector_int → vector
We then subs*tute all occurrences of int with T
class vector {
public:
using iterator = T*;
using const_iterator = T const*;
vector(std::size_t sz): sz(sz), elem(new T[sz]) {...}
T& operator(std::size_t i) { return elem[i]; }
T const& operator(std::size_t i) const { return elem[i]; }
...
private:
std::size_t sz;
T* elem;
};

vector
As a result, we obtained a non-resizable container of con5guously-
allocated elements of type T
vector<double> v(3);
v[0] = 7.1;
v[1] = 2.9;
v[2] = 5.3;

vector preserves regularity
Moreover, vector is as regular as its element type
// T is either a semi-regular,
// regular or totally ordered type
class vector { ... }

vector preserves regularity
In other words, vector is a regularity-preserving type constructor
// T is either a semi-regular,
// regular or totally ordered type
class vector { ... }

vector vs. min_element
void print_min(vector<double> v) {
vector<double>::iterator first = v.begin();
vector<double>::iterator last = v.end();
vector<double>::iterator m = min_element(first, last);
if (m != last)
}

vector vs. min_element
void print_min(vector<double> v) {
auto first = v.begin();
auto last = v.end();
auto m = min_element(first, last);
if (m != last)
}

The book regular type
class book {
public:
book() {}
book(std::string title,
std::string isbn,
int pub_year): title(title), isbn(isbn), pub_year(pub_year) {}
bool operator<(book const& b) const { return isbn < b.isbn; }
bool operator==(book const& b) const { return isbn == b.isbn; }
// definitions for !=, <, >=, <=
private:
std::string title;
std::string isbn;
int pub_year;
};

Finding the minimum book
Hence, we can ﬁnd the lexicographic minimum book in a vector as:
std::vector<book> bs = ...
auto m = min_element(bs.begin(), bs.end());

Finding the most ancient book
What if we want to ﬁnd instead the most ancient book?
class book {
public:
...
private:
std::string title;
std::string isbn;
int pub_year;
};

Unfortunately, there could be only one natural order for a class
class book {
public:
...
private:
std::string title;
std::string isbn;
int pub_year;
};

Moreover, min_element is wri+en so as to use operator <
I min = first; ++first;
++first;
}
return min;
}

Less-than operator
However, forcing the use of operator < seems an arbitrary choice
++first;
}
return min;
}

Less-than operator
This is evident if we use the func/onal nota/on3
of operator<
if (operator<(*first, *min)) min = first;
++first;
}
return min;
}
3
With the caveat that such a nota/on is not possible when the value type of I is a built-in type

Less-than operator
In fact, operator< is just one out of many ordering criteria
if (operator<(*first, *min)) min = first;
++first;
}
return min;
}

A generalized version of min_element
Therefore, the following looks like a be3er generaliza5on:
template <typename I, typename C>
I min_element(I first, I last, C cmp) {
if (cmp(*first, *min)) min = first;
++first;
}
return min;
}

On the nature of cmp
Since cmp is invoked, one would say that cmp is a func%on
if (cmp(*first, *min)) min = first;

On the nature of cmp
However, cmp is also passed as an input argument, therefore it also
looks like an object
I min_element(I first, I last, C cmp) { ... }

Func%on object
It turns out that cmp is an object that behaves like a func3on

Func%on object
We refer to such objects as func%on objects4
4
Func'on objects are also called functors. However, we prefer not to use such a term, since outside the C++
community it is used to indicate a very diﬀerent concept

Func%on object
In order to make an object look like a func3on we need to overload
the call operator ()

converter func. object
class converter {
public:
converter(double er): exchange_rate(er) {}
double operator()(double amount) const {
return amount * exchange_rate;
}
private:
double exchange_rate;
};

converter func. object
Once ini'alized with the exchange rate, we can invoke the func'on
object just like a plain func'on
converter eur_to_usd(1.1);
double euros;
std::cin >> euros;
std::cout << eur_to_usd(euros);

The advantage of func. objects
The advantage of func/on objects is that they can be eﬃciently
passed to func/ons and consequently invoked

Comparing books by pub_year
In light of this, we need a func3on object that will take two books
and verify if the ﬁrst one is older than the second5
struct by_pub_year {
bool operator()(book const& b1,
book const& b2) const {
return b1.pub_year() < b2.pub_year();
}
};
5
Here, we are assuming the existence of an access func5on named pub_year()

Comparing books by pub_year
With by_pub_year in place, we can ﬁnally look for the most
ancient book
auto m = min_element(bs.begin(),
bs.end(), by_pub_year());

Default comparison
However, we would s-ll like to default to operator< when no
custom func-on object is passed
auto min_isbn = min_element(bs.begin(), bs.end());

less func&on object
To this extent, let us ﬁrst write a func4on object to serve as the
default comparator, which we call less6
struct less {
template <typename T> // T is a totally ordered type
bool operator(T const& e1, T const& e2) const {
return e1 < e2;
}
};
6
In the C++ Standard, the type parameteriza4on is on the class, rather than on the operator overload. That is, the
standard default comparator is of type std::less<T>

min_element overload
Then, we provide an overload of min_element which wraps the
more general func7on
return min_element(first, last, less());
}

Finding the minimum book
Thanks to this, we are free to decide if we want to pass or not a
custom comparator
auto min_isbn = min_element(bs.begin(), bs.end());
auto min_pub = min_element(bs.begin(), bs.end(), by_pub_year());

Does by_pub_year induce a strict total order on books?

py_pub_year vs. strict total order
As a ma&er of fact, by_pub_year does not induce a strict total
order
struct by_pub_year {
...
};

py_pub_year vs. strict total order
Indeed, the trichotomy law would impose two books with the same
publishing date to be the same
!by_pub_year({"The dubliners", 1914}, {"The metamorphosis ", 1914}) &&
!by_pub_year({"The metamorphosis ", 1914}, {"The dubliners", 1914})

Equivalent rela-on
No#ce that the property of having the same publishing date is an
equivalent rela,on

Equivalent classes
As such, it par--ons the set of books into equivalent classes
┌───────────┬──────────────────────────────┬─────────┐
│ │ * * │ │
│ * │ * 1851 * │ * │
│ * │ * * │ * │
│ * │─────────────────────┬────────│ * │
│ │ * │ │ │
│ │ * 2005 * │ * │ 1712 │
│ 1987 │ * * │ │ │
│ │──────────┬──────────┤ 2016 │ * * │
│ * │ │ * │ │ │
│ * │ * * │ * │ * * │ │
│ * │ │ │────────┴─────────┤
│ │ 1901 │ 1301 │ * * │
│ * │ * * │ │ 1510 │
│ * * │ * │ * │ * * │
│ │ │ │ │
└───────────┴──────────┴──────────┴──────────────────┘

Strict weak ordering
A strict weak ordering is an ordering rela-on that is strict,
transi/ve and obeys the weak-trichotomy law

Weak-trichotomy law
An ordering rela,on r obeys the weak-trichotomy law if
!r(a, b) && !r(b, a) is the same as eq(a, b),
for some equivalent rela0on eq

Weak vs. total ordering
Therefore, a strict total ordering is a par-cular case of weak total
ordering in which equality is used as the equivalent rela-on

min_element requirements
Finally, we can state the correct requirements for min_element
// C defines a strict weak ordering on I's value type

Generic programming
The Standard Template Library is the most successful example of a
programming paradigm called generic programming7
7
With the Boost library steadily holding the second posi5on

Generic programming
Generic programming is an approach to programming that focuses
on designing algorithms and data structures so that they work in
the most general se0ng without loss of eﬃciency

Generic programming
That is, generic programming is a way of developing so7ware that
maximizes code reuse without sacriﬁcing performance

Generic programming
Generic programming achieves this through parameteriza)on

Parameteriza)on
We can parameterize a type with another (such as a vector with
its element type)
class vector {
...
}

Parameteriza)on
We can parameterize an algorithm with an other (such as the
min_element func6on with a comparison func. object)
I min_element(I first, I last, C cmp) {...}

Polymorphism
Non-generic func-ons are monomorphic, i.e., they operate on one
data type
int* min_element(int* first, int* last) {...}

Polymorphism
For example, the following non-generic version of min_element is
speciﬁc to arguments of type int*
int* min_element(int* first, int* last) {...}

Polymorphism
On the contrary, generic func1ons are polymorphic, i.e., they
operate on any data type so long as their requirements hold
// C defines a strict weak ordering on I's value type
I min_element(I first, I last, C cmp) {...}

Parametric polymorphism
This form of polymorphism is usually called parametric
polymorphism, as opposed to ad-hoc polymorphism, which is
typical of the object-oriented paradigm

Most general algorithms
Generic programming tries to discover polymorphic func6ons by
observing that several monomorphic func6ons all share a similar
structure

Most general algorithms
That is, generic programming tries to deﬁne algorithms in terms of
the most general concepts

Avoid par*al solu*ons
The availability of correct generic algorithms allows developers to
avoid wri7ng their own par$ally correct ones

Thanks to this, developers can avoid using statements such as for
and while that can cause non-robust behavior

With min_element, we should not need any more to iterate over
a container with a for loop just for the sake of ﬁnding the
minimum element

"Photoshop is roughly 3 million lines of code last 7me I counted, which
means I think we will be able to express the en7re Photoshop in about
30 thousand lines of code"
(S. Parent)

Before using the STL
void PanelBar::RepositionExpandedPanels(Panel* fixed_panel) {
CHECK(fixed_panel);
// First, find the index of the fixed panel.
int fixed_index = GetPanelIndex(expanded_panels_, *fixed_panel);
CHECK_LT(fixed_index, expanded_panels_.size());
// Next, check if the panel has moved to the other side of another panel.
const int center_x = fixed_panel->cur_panel_center();
for (size_t i = 0; i < expanded_panels_.size(); ++i) {
Panel* panel = expanded_panels_[i].get();
if (center_x <= panel->cur_panel_center() ||
i == expanded_panels_.size() - 1) {
if (panel != fixed_panel) {
// If it has, then we reorder the panels.
ref_ptr<Panel> ref = expanded_panels_[fixed_index];
expanded_panels_.erase(expanded_panels_.begin() + fixed_index);
if (i < expanded_panels_.size()) {
expanded_panels_.insert(expanded_panels_.begin() + i, ref);
} else {
expanded_panels_.push_back(ref);
}
}
break;
}
}

A"er using the STL
// Next, check if the panel has moved to the left side of another panel.
auto f = begin(expanded_panels_) + fixed_index;
auto p = lower_bound(begin(expanded_panels_), f, center_x,
[](const ref_ptr<Panel>& e, int x){ return e->cur_panel_center() < x; });
// If it has, then we reorder the panels.
rotate(p, f, f + 1);

Bibliography
• B. Stroustrup, Programming: Principles and Prac8ce
Using C++ (2nd
ed.)
• A. Stepanov, P. McJones, Elements of programming
• A. Stepanov, D. Rose, From Mathema8cs to Generic
Programming

Bibliography
• A. Stepanov, Notes on programming
• A. Stepanov, Eﬃcient Programming with Components Lecture 4
• A. Stepanov, Eﬃcient Programming with Components Lecture 11
• S. Parent, A Possible Future of SoCware Development
• S. Parent, Programming ConversaEons Lecture 5
• S. T. Lavavej, Standard Template Library (STL), 1 of n

Bibliography
• B. Stroustrup, C++ in 2005
• B. Stroustrup, What is "generic programming"?
• ISO C++, What's the big deal with generic programming?

C++ Standard Template Library

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to C++ Standard Template Library

Similar to C++ Standard Template Library (20)

More from Ilio Catallo

More from Ilio Catallo (18)

Recently uploaded

Recently uploaded (20)

C++ Standard Template Library