Additional note about solved problems.

source/sorting-algorithms.tex

@@ -35,7 +35,7 @@ \section{Motivation and Scope}
 It is probably a dumb idea to define a \tcode{sort} as a member function of a container, but it is not unheard of and it makes a good example of what not to do.
 \end{quotation}
 
-That said, \tcode{std::list::sort} and \tcode{std::forward\_list::sort} have a reason to exist: these algorithms can make more assumptions knowing that they work on list data structures, allowing for a  $\mathcal{O}(\log{} n)$ space complexity instead of a  $\mathcal{O}(n)$ one for a classic mergesort. Moreover, these functions don't invalidate the iterators and even work when the stored elements are not moveable. These improvements are due to the ability that lists have to relink nodes instead of moving values around. However, this approach is hardly generic: it only allows to sort full lists instead of arbitrary pairs of iterators, and it forces to add a corresponding member function \tcode{sort} to custom classes wrapping a list and offering an iterator interface.
+That said, \tcode{std::list::sort} and \tcode{std::forward\_list::sort} have a reason to exist: these algorithms can make more assumptions knowing that they work on list data structures, allowing for a  $\mathcal{O}(\log{} n)$ space complexity instead of a  $\mathcal{O}(n)$ one for a classic mergesort. Moreover, these functions don't invalidate the iterators and even work when the stored elements are not moveable. These improvements are due to the ability that lists have to relink nodes instead of moving values around. However, this approach is hardly generic: it only allows to sort full lists instead of arbitrary pairs of iterators, and it forces to add a corresponding member function \tcode{sort} to custom classes wrapping a list and offering an iterator interface. Weakening the iterator categories of the generic sorting algorithms would solve both of these problems.
 
 \vspace{0.3cm}