Work on data-structures

Author: nowox

_templates/layout.html

@@ -0,0 +1,4 @@
+{% extends "!layout.html" %}
+{% block extrahead %}
+    <link href="{{ pathto("_static/custom.css", True) }}" rel="stylesheet" type="text/css">
+{% endblock %}

assets/figures

@@ -0,0 +1,34 @@
+#include <stdio.h>
+#include <stdbool.h>
+
+#define SIZE 1000
+
+bool cache_input[SIZE] = { false };
+int cache_output[SIZE];
+
+int memoize(int input, int output) {
+    cache_input[input % SIZE] = true;
+    cache_output[input % SIZE] = output;
+    return output;
+}
+
+bool memoize_has(int input) {
+    return cache_input[input % SIZE];
+}
+
+int memoize_get(int input) {
+    return cache_output[input % SIZE];
+}
+
+int fib(int n)
+{
+    if (memoize_has(n)) return memoize_get(n);
+    if (n < 2) return 1;
+    return memoize(n, fib(n - 1) + fib(n - 2));
+}
+
+int main() {
+    for (int i = 0; i < 40; i++) {
+        printf("%d\n", fib(i));
+    }
+}

assets/src/memoize.c

@@ -733,10 +733,15 @@ L'utilisation d'un type énuméré peut être la suivante :
         }
     }
 
+Type incomplet
+==============
+
+Un type incomplet est un qualificatif de type de donnée décrivant un objet dont sa taille en mémoire n'est pas connue.
+
 Type vide (*void*)
 ==================
 
-Le type ``void`` est particulier car c'est un type qui ne vaut rien. Il est utilisé comme type de retour pour les fonctions qui ne retournent rien :
+Le type ``void`` est particulier. Il s'agit d'un type dit **incomplet** car la taille de l'objet qu'il représente en mémoire n'est pas connue. Il est utilisé comme type de retour pour les fonctions qui ne retournent rien :
 
 .. code-block:: c
 

content/20-datatype.rst

@@ -279,6 +279,146 @@ En des termes plus corrects, mais nous verrons cela au chapitre sur les pointeur
 
 Retenez simplement que lors d'un passage par référence, on cherche à rendre la valeur passée en paramètre modifiable par le *caller*.
 
+Récursion
+=========
+
+La récursion, caractère d'un processus, d'un mécanisme récursif, c'est à dire qui peut être répété un nombre indéfini de fois par l'application de la même règle, est une méthode d'écriture dans laquelle une fonction s'appelle elle même.
+
+Au chapitre sur les fonctions, nous avions donné l'exemple du calcul de la somme de la suite de fibonacci jusqu'à ``n`` :
+
+.. code-block:: c
+
+    int fib(int n)
+    {
+        int sum = 0;
+        int t1 = 0, t2 = 1;
+        int next_term;
+        for (int i = 1; i <= n; i++)
+        {
+            sum += t1;
+            next_term = t1 + t2;
+            t1 = t2;
+            t2 = next_term;
+        }
+        return sum;
+    }
+
+Il peut sembler plus logique de raisonner de façon récursive. Quelque soit l'itération à laquelle l'on soit, l'assertion suivante est valable :
+
+    fib(n) == fib(n - 1) + fib(n - 2)
+
+Donc pourquoi ne pas réécrire cette fonction en employant ce caractère récursif ?
+
+.. code-block:: c
+
+    int fib(int n)
+    {
+        if (n < 2) return 1;
+        return fib(n - 1) + fib(n - 2);
+    }
+
+Le code est beaucoup plus simple a écrire, et même à lire. Néanmoins cet algorithme est notoirement connu pour être mauvais en terme de performance. Calculer ``fib(5)`` revient à la chaîne d'appel suivant.
+
+Cette chaîne d'appel représente le nombre de fois que ``fib`` est appelé et à quel niveau elle est appelée. Par exemple ``fib(4)`` est appelé dans ``fib(5)`` :
+
+.. code-block:: text
+
+    fib(5)
+        fib(4)
+            fib(3)
+                fib(2)
+                fib(1)
+            fib(2)
+                fib(1)
+                fib(0)
+        fib(3)
+            fib(2)
+                fib(1)
+                fib(0)
+            fib(1)
+
+Si l'on somme le nombre de fois que chacune de ces fonctions est appelée :
+
+.. code-block:: text
+
+    fib(5)   1x
+    fib(4)   1x
+    fib(3)   2x
+    fib(2)   3x
+    fib(1)   4x
+    fib(0)   2x
+    -----------
+    fib(x)  13x
+
+Pour calculer la somme de fibonacci, il faut appeler 13 fois la fonction. On le verra plus tard mais la complexité algoritmique de cette fonction est dite :math:`O(2^n)`. C'est à dire que le nombre d'appels suit une relation exponentielle. La réelle complexité est donnée par la relation :
+
+.. math::
+
+    T(n) = O\left(\frac{1+\sqrt(5)}{2}^n\right) = O\left(1.6180^n\right)
+
+Ce terme 1.6180 est appelé `le nombre d'or <https://fr.wikipedia.org/wiki/Nombre_d%27or>`__.
+
+Ainsi pour calculer fib(100) il faudra sept cent quatre-vingt-douze trillions soixante-dix mille huit cent trente-neuf billions huit cent quarante-huit milliards trois cent soixante-quatorze millions neuf cent douze mille deux cent quatre-vingt-douze appels à la fonction `fib` (792'070'839'848'374'912'292). Pour un processeur Core i7 (2020) capable de calculer environ 100 GFLOPS (milliards d'opérations par seconde), il lui faudra tout de même 251 ans.
+
+En revanche, dans l'approche itérative, on constate qu'une seule boucle ``for``. C'est à dire qu'il faudra seulement 100 itérations pour calculer la somme.
+
+Généralement les algorithmes récursifs (s'appelant eux même) sont moins performants que les algorithmes itératifs (utilisant des boucles). Néanmoins il est parfois plus facile d'écrire un algorithme récursif.
+
+Notons que tout algorithme récursif peut être écrit en un algorithme itératif, mais ce n'est pas toujours facile.
+
+Mémoïsation
+===========
+
+En informatique la `mémoïsation <https://fr.wikipedia.org/wiki/M%C3%A9mo%C3%AFsation>`__ est une technique d'optimisation du code souvent utilisée conjointement avec des algorithmes récursifs. Cette technique est largement utilisée en `programmation dynamique <https://fr.wikipedia.org/wiki/Programmation_dynamique>`__.
+
+Nous l'avons vu précédemment, l'algorithme récursif du calcul de la somme de la suite de Fibonacci n'est pas efficace du fait que les mêmes appels sont répétés un nombre inutiles de fois. La parade est de mémoriser pour chaque appel de ``fib``, la sortie correspondante à l'entrée.
+
+Dans cet exemple nous utiliserons un mécanisme composé de trois fonctions :
+
+- ``int memoize(Cache *cache, int input, int output)``
+- ``bool memoize_has(Cache *cache, int input)``
+- ``int memoize_get(Cache *cache, int input)``
+
+La première fonction mémorise la valeur de sortie ``output`` liée à la valeur d'entrée ``input``. Pour des raisons de simplicité d'utilsation, la fonction retourne la valeur de sortie ``output``.
+
+La seconde fonction ``memoize_has`` vérifie si une valeur de correspondance existe pour l'entrée ``input``. Elle retourne ``true`` en cas de correspondance et ``false`` sinon.
+
+La troisième fonction ``memoize_get`` retourne la valeur de sortie correspondante à la valeur d'entrée ``input``.
+
+Notre fonction récursive sera ainsi modifiée comme suit :
+
+.. code-block:: c
+
+    int fib(int n)
+    {
+        if (memoize_has(n)) return memoize_get(n);
+        if (n < 2) return 1;
+        return memoize(n, fib(n - 1) + fib(n - 2));
+    }
+
+Quant aux trois fonctions utilitaires, voici une proposition d'implémentation. Notons que cette implémentation est très élémentaire et n'est valable que pour des entrées inférieures à 1000. Il sera possible ultérieurement de perfectionner ces fonctions, mais nous aurons pour cela besoin de concepts qui n'ont pas encore été abordés, tels que les structures de données complexes.
+
+.. code-block:: c
+
+    #define SIZE 1000
+
+    bool cache_input[SIZE] = { false };
+    int cache_output[SIZE];
+
+    int memoize(int input, int output) {
+        cache_input[input % SIZE] = true;
+        cache_output[input % SIZE] = output;
+        return output;
+    }
+
+    bool memoize_has(int input) {
+        return cache_input[input % SIZE];
+    }
+
+    int memoize_get(int input) {
+        return cache_output[input % SIZE];
+    }
+
 ------
 
 .. exercise:: Dans la moyenne

content/40-functions.rst

@@ -59,6 +59,7 @@ Lorsqu'un programme à besoin de mémoire, il peut générer un appel système p
 
 L'allocation se fait sur le `tas` (*heap*) qui est de taille variable. À chaque fois qu'un espace mémoire est demandé, ``malloc`` recherche dans le segment un espace vide de taille suffisante, s'il ne parvient pas, il exécute l'appel système `sbrk <https://en.wikipedia.org/wiki/Sbrk>`__ qui permet de déplacer la frontière du segment mémoire et donc d'agrandir le segment.
 
+.. _fig_allocation:
 .. figure:: ../assets/figures/dist/memory/malloc.*
 
 Mémoire de programme
@@ -265,3 +266,53 @@ allez piétiner les zones mémoires voisines sans en avoir la permission.
 Le compilateur (en réalité l'éditeur de liens - le *linker*) vous permet
 de spécifier la taille de la pile ; c'est une de ses nombreuses options.
 
+Variables automatiques
+======================
+
+Une variable est dite *automatique* lorsque sa déclaration est faite au sein d'une fonction. La variable d'itération ``int i`` dans une boucle ``for`` est dite automatique. C'est à dire que le compilateur à le choix de placer cette variable :
+
+- sur la pile ;
+- dans un registre mémoire processeur.
+
+Jadis, le mot clé ``register`` était utiliser pour forcer le compilateur à placer une variable locale dans un registre processeur pour obtenir de meilleures performances. Aujourd'hui, les compilateurs sont assez malins pour déterminer automatiquement les variables souvent utilisées.
+
+Fragmentation mémoire
+=====================
+
+On peut observer à la figure :numref:`fig_allocation` qu'après un appel successif de ``malloc`` et de ``free`` des espaces mémoires non utilisés peuvent apparaître entre des régions utilisées. Ces *trous* sont appelés fragmentation mémoire.
+
+Dans la figure suivante, on suit l'évolution de l'utilisation du *heap* au cours de la vie d'un programme. Au début ➀, la mémoire est libre. Tant que de la mémoire est allouée sans libération (``free``), aucun problème de fragmentation ➁. Néanmoins, après un certain temps la mémoire devient fragmentée ➂ ; il reste dans cet exemple 2 emplacements de taille 2, un emplacement de taille 5 et un emplacement de taille 8. Il est donc impossible de réserver un espace de taille 9 malgré que l'espace cumulé libre est suffisant.
+
+.. figure:: ../assets/figures/dist/memory/fragmentation.*
+
+Dans une petite architecture, l'allocation et la libération fréquente d'espaces mémoire de taille arbitraire est malvenue. Une fois que la fragmentation mémoire est installée, il n'existe aucun moyen de soigner le mal si ce n'est au travers de l'ultime solution de l'informatique : `éteindre puis redémarrer <https://www.youtube.com/watch?v=nn2FB1P_Mn8>`__.
+
+MMU
+---
+
+Les systèmes d'exploitations modernes (Windows, Linux, macOS...) utilisent tous un dispositif matériel nommé `MMU <https://en.wikipedia.org/wiki/Memory_management_unit>`__ pour *Memory Management Unit*. La MMU est en charge de créer un espace mémoire **virtuel** entre l'espace physique. Cela crée une indirection supplémentaire mais permet de réorganiser la mémoire physique sans compromettre le système.
+
+En pratique l'espace de mémoire virtuelle est toujours beaucoup plus grand que l'espace physique. Cela permet de s'affranchir dans une large mesure de problèmes de fragmentation car si l'espace virtuel est suffisament grand, il y aura statistiquement plus de chance d'y trouver un emplacement non utilisé.
+
+La programmation sur de petites architectures matérielles (microcontrôleurs, DSP) ne possèdent pas de MMU et dès lors l'allocation dynamique est généralement à proscrire à moins qu'elle soit faite en connaissance de cause et en utilisant des mécanisme comme les *memory pool*.
+
+Dans la figure ci-dessous. La mémoire physique est représentée à droite en termes de pages mémoires physiques (*Physical Pages* ou **PP**). Il s'agit de blocs mémoires contigus d'une taille fixe, par exemple 64 kB. Chaque page physique est mappée dans une table propre à chaque processus (programme exécutable). On y retrouve quelques proriétés utiles à savoir est-ce que la page mémoire est accessible en écriture, est-ce qu'elle peut contenir du code exécutable ? Une propriété peut indiquer par exemple si la page mémoire est valide. Chacune de ces entrées est considérée comme une page mémoire virtuelle (*virtual page* **VP**).
+
+.. figure:: ../assets/figures/dist/memory/mmu.*
+
+Erreurs de segmentation (*segmentation fault*)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Lorsqu'un programme tente d'accéder à un espace mémoire qui n'est pas mappé dans la MMU, ou que cet espace mémoire ne permet pas le type d'accès souhaité : par exemple une écriture dans une page en lecture seule. Le système d'exploitation tue le processus avec une erreur *Segmentation Fault*. C'est la raison pour laquelle, il n'est pas systématique d'avoir une erreur de segmentation en cas de jarinage mémoire. Tant que les valeurs modifées sont localisées au sein d'un bloc mémoire autorisé, il n'y aura pas d'erreur.
+
+L'erreur de segmentation est donc générée par le système d'exploitation en lèvant le signal **SIGSEGV** (Violation d'accès à un segment mémoire, où erreur de segmentation).
+
+Memory Pool
+-----------
+
+Un *memory pool* est une méthode faisant appel à de l'allocation dynamique de blocs de taille fixe. Lorsqu'un programme doit très régulièrement allouer et désalouer de la mémoire, il est préférable que les blocs mémoire ait une taille fixe. De cette façon, après un ``free``, la mémoire libérée est assez grande pour une allocation ultérieure.
+
+Lorsqu'un programme est exécuté sous Windows, macOS ou Linux, l'allocation dynamique standard ``malloc``, ``calloc``, ``realloc`` et ``free`` sont performants et le risque de crash dû à une fragmentation mémoire est rare.
+
+En revanche lors de l'utilisation sur de petites architectures (microcontrôleurs) qui n'ont pas de système sophistiqués pour gérer la mémoire, il est parfois nécessaire d'écrire son propre système de gestion de mémoire.
+

content/55-memory-management.rst

@@ -177,6 +177,27 @@ Programmation dynamique
 
 .. todo:: Compléter
 
+Algorithmes de tris
+===================
+
+Heap Sort
+---------
+
+
+
+.. code-block:: text
+
+                 8
+                 |
+             ----+----
+           /           \
+          4            12
+         --            --
+       /    \        /    \
+      20     6      42    14
+     / \    / \    / \   /  \
+    11  3  35  7  9  11 50  16
+
 -----
 
 .. exercise:: Intégrateur de Kahan

content/77-algorithms.rst

@@ -1,4 +1,6 @@
 
+.. _TranslationUnits:
+
 ===================
 Compilation séparée
 ===================
@@ -31,7 +33,7 @@ Ainsi, lorsque le programme commence à être volumineux, sa lecture, sa compré
     ├── complex.h
     └── main.c
 
-Le programme principal et la fonction ``main`` est contenu dans ``main.c`` quant au module *complex* il est composé de deux fichiers : ``complex.h`` l'en-tête et ``complex.c``, l'implémentation du module. 
+Le programme principal et la fonction ``main`` est contenu dans ``main.c`` quant au module *complex* il est composé de deux fichiers : ``complex.h`` l'en-tête et ``complex.c``, l'implémentation du module.
 
 Le fichier ``main.c`` devra inclure le fichier ``complex.h`` afin de
 pourvoir utiliser correctement les fonctions du module de gestion des
@@ -44,7 +46,7 @@ nombres complexes. Exemple :
 
     int main() {
         Complex c1 = { .real = 1., .imag = -3. };
-        complex_fprint(stdout, c1); 
+        complex_fprint(stdout, c1);
     }
 
 .. code-block:: c
@@ -86,43 +88,43 @@ Cet exemple sera compilé dans un environnement POSIX de la facon suivante :
     gcc -c main.c -o main.o
     gcc complex.o main.o -oprogram -lm
 
-Nous verrons plus bas les éléments théoriques vous permettant de mieux comprendre ces lignes. 
+Nous verrons plus bas les éléments théoriques vous permettant de mieux comprendre ces lignes.
 
 Module logiciel
 ===============
 
-Les applications modernes dépendent souvent de nombreux modules logiciels externes aussi utilisés dans d'autres projets. C'est avantageux à plus d'un titre : 
+Les applications modernes dépendent souvent de nombreux modules logiciels externes aussi utilisés dans d'autres projets. C'est avantageux à plus d'un titre :
 
 - les modules externes sont sous la responsabilité d'autres développeurs et le programme a développer comporte moins de code ;
 - les modules externes sont souvent bien documentés et testés et il est facile de les utiliser ;
 - la lisibilité du programme est accrue car il est bien découpé en des ensembles fonctionnels ;
 - les modules externes sont réutilisables et indépendants, ils peuvent donc être réutilisés sur plusieurs projets.
 
-Lorsque vous utiliser la fonction ``printf``, vous dépendez d'un module externe nommé ``stdio``. En réalité l'ensemble des modules ``stdio``, ``stdlib``, ``stdint``, ``ctype``... sont tous groupé dans une seule bibliothèque logicielle nommée ``libc`` disponible sur tous les systèmes compatibles POSIX. Sous Linux, le pendant libre ``glibc`` est utilisée. Il s'agit de la biblothèque `GNU C Library <https://fr.wikipedia.org/wiki/GNU_C_Library>`__. 
+Lorsque vous utiliser la fonction ``printf``, vous dépendez d'un module externe nommé ``stdio``. En réalité l'ensemble des modules ``stdio``, ``stdlib``, ``stdint``, ``ctype``... sont tous groupé dans une seule bibliothèque logicielle nommée ``libc`` disponible sur tous les systèmes compatibles POSIX. Sous Linux, le pendant libre ``glibc`` est utilisée. Il s'agit de la biblothèque `GNU C Library <https://fr.wikipedia.org/wiki/GNU_C_Library>`__.
 
-Un module logiciel peut se composer de fichiers sources, c'est à dire un ensemble de fichiers ``.c`` et ``.h`` ainsi qu'une documentation et un script de compilation (``Makefile``). Alternativement, un module logiciel peut se composer de bibliothèques déjà compilées sous la forme de fichiers ``.h``, ``.a`` et ``.so``. Sous Windows on rencontre fréquemment l'extension ``.dll``. Ces fichiers compilés ne donnent pas accès au code source mais permettent d'utiliser les fonctionnalités quelles offrent dans des programmes C en mettant à disposition un ensemble de fonctions documentées. 
+Un module logiciel peut se composer de fichiers sources, c'est à dire un ensemble de fichiers ``.c`` et ``.h`` ainsi qu'une documentation et un script de compilation (``Makefile``). Alternativement, un module logiciel peut se composer de bibliothèques déjà compilées sous la forme de fichiers ``.h``, ``.a`` et ``.so``. Sous Windows on rencontre fréquemment l'extension ``.dll``. Ces fichiers compilés ne donnent pas accès au code source mais permettent d'utiliser les fonctionnalités quelles offrent dans des programmes C en mettant à disposition un ensemble de fonctions documentées.
 
 Compilation avec assemblage différé
 ===================================
 
-Lorsque nous avions compilé notre premier exemple `Hello World <hello>`__ nous avions simplement appelé ``gcc`` avec le fichier source ``hello.c`` qui nous avait créé un exécutable ``a.out``. En réalité, GCC est passé par plusieurs sous étapes de compilation : 
+Lorsque nous avions compilé notre premier exemple `Hello World <hello>`__ nous avions simplement appelé ``gcc`` avec le fichier source ``hello.c`` qui nous avait créé un exécutable ``a.out``. En réalité, GCC est passé par plusieurs sous étapes de compilation :
 
 1. **Préprocessing** : les commentaires sont retirés, les directives pré-processeur sont remplacées par leur équivalent C.
 2. **Compilation** : le code C d'une seule *translation unit* est converti en langage machine en un fichier objet ``.o``.
 3. **Édition des liens** : aussi nommé *link*, les différents fichiers objets sont réunis en un seul exécutable.
 
-Lorsqu'un seul fichier est fourni à GCC, les trois opérations sont effectuées en même temps mais ce n'est plus possible aussitôt que le programme est composé de plusieurs unités de translation (plusieurs fichiers C). Il est alors nécessaire de compiler manuellement chaque fichier source et d'en créer. 
+Lorsqu'un seul fichier est fourni à GCC, les trois opérations sont effectuées en même temps mais ce n'est plus possible aussitôt que le programme est composé de plusieurs unités de translation (plusieurs fichiers C). Il est alors nécessaire de compiler manuellement chaque fichier source et d'en créer.
 
-La figure suivante résume les différentes étapes de GCC. Les pointillés indiquent à quel niveau les opérations peuvent s'arrêter. Il est dès lors possible de passer par des fichiers intermédiaires assembleur (``.s``) ou objets (``.o``) en utilisant la bonne commande. 
+La figure suivante résume les différentes étapes de GCC. Les pointillés indiquent à quel niveau les opérations peuvent s'arrêter. Il est dès lors possible de passer par des fichiers intermédiaires assembleur (``.s``) ou objets (``.o``) en utilisant la bonne commande.
 
 .. figure:: ../assets/figures/dist/toolchain/gcc.*
 
-Notons que ces étapes existent quelque soit le compilateur ou le système d'exploitation. Nous retrouverons ces exactes mêmes étapes avec Microsoft Visual Studio mais le nom des commandes et les extensions des fichiers peuvent varier s'ils ne respectent pas la norme POSIX (et GNU). 
+Notons que ces étapes existent quelque soit le compilateur ou le système d'exploitation. Nous retrouverons ces exactes mêmes étapes avec Microsoft Visual Studio mais le nom des commandes et les extensions des fichiers peuvent varier s'ils ne respectent pas la norme POSIX (et GNU).
 
-Notons que généralement, seul deux étapes de GCC sont utilisées : 
+Notons que généralement, seul deux étapes de GCC sont utilisées :
 
 1. Compilation avec ``gcc -c <fichier.c>``, ceci génère automatiquement un fichier ``.o`` du même nom que le fichier d'entrée.
-2. Édition des liens avec ``gcc <fichier1.o> <fichier2.o> ...``, ceci génère automatiquement un fichier exécutable ``a.out``. 
+2. Édition des liens avec ``gcc <fichier1.o> <fichier2.o> ...``, ceci génère automatiquement un fichier exécutable ``a.out``.
 
 Fichiers d'en-tête (*header*)
 =============================
@@ -133,7 +135,7 @@ Les fichiers d'en-tête (``.h``) sont des fichiers écrits en langage C mais qui
 - Des déclaration de types (``typedef``, ``struct``).
 - Des définitions pré-processeur (``#include``, ``#define``).
 
-Nous l'avons vu dans le chapitre sur le pré-processeur, la directive ``#include`` ne fait qu'inclure le contenu du fichier cible à l'emplacement de la directive. Il est donc possible (mais fort déconseillé), d'avoir la situation suivante : 
+Nous l'avons vu dans le chapitre sur le pré-processeur, la directive ``#include`` ne fait qu'inclure le contenu du fichier cible à l'emplacement de la directive. Il est donc possible (mais fort déconseillé), d'avoir la situation suivante :
 
 .. code-block:: c
 
@@ -142,32 +144,32 @@ Nous l'avons vu dans le chapitre sur le pré-processeur, la directive ``#include
        #include "foobar.def"
     }
 
-Et le fichier ``foobar.def`` pourrait cotenir : 
+Et le fichier ``foobar.def`` pourrait cotenir :
 
 .. code-block:: c
 
-    // foobar.def 
-    #ifdef FOO   
+    // foobar.def
+    #ifdef FOO
     printf("hello foo!\n");
     #else
     printf("hello bar!\n");
     #endif
 
-Vous noterez que l'extension de ``foobar`` n'est pas ``.h`` puisque le contenu n'est pas un fichier d'en-tête. ``.def`` ou n'importe quelle autre extension pourrait donc faire l'affaire ici. 
+Vous noterez que l'extension de ``foobar`` n'est pas ``.h`` puisque le contenu n'est pas un fichier d'en-tête. ``.def`` ou n'importe quelle autre extension pourrait donc faire l'affaire ici.
 
-Dans cet exemple, le pré-processeur ne fait qu'inclure le contenu du fichier ``foobar.def`` à l'emplacement de la définition ``#include "foobar.def"``. Voyons le en détail : 
+Dans cet exemple, le pré-processeur ne fait qu'inclure le contenu du fichier ``foobar.def`` à l'emplacement de la définition ``#include "foobar.def"``. Voyons le en détail :
 
-.. code-block:: c
+.. code-block:: console
 
     $ cat << EOF > main.c
     → int main() {
     →     #include "foobar.def"
-    →     #include "foobar.def"    
+    →     #include "foobar.def"
     → }
     → EOF
 
     $ cat << EOF > foobar.def
-    → #ifdef FOO   
+    → #ifdef FOO
     → printf("hello foo!\n");
     → #else
     → printf("hello bar!\n");
@@ -177,12 +179,12 @@ Dans cet exemple, le pré-processeur ne fait qu'inclure le contenu du fichier ``
     $ gcc -E main.c | sed '/^#/ d'
     int main() {
     printf("hello bar\n");
-    printf("hello bar\n");    
+    printf("hello bar\n");
     }
 
 Lorsque l'on observe le résultat du pré-processeur, on s'aperçois que toutes les directives préprocesseur ont disparues et que la directive ``#include`` a été remplacée par de contenu de ``foobar.def``. Remarquons que le fichier est inclus deux fois, nous verrons plus loin comme éviter cela.
 
-Nous avons vu au chapitre sur les `prototypes de fonctions <function_prototype>`__ qu'il est possible de ne déclarer que la première ligne d'une fonction. Ce prototype permet au compilateur de savoir combien d'arguments est composé une fonction sans nécessairement disposer de l'implémentation de cette fonction. Aussi on trouve dans tous les fichiers d'en-tête des déclaration en amont (*forward declaration*). Dans le fichier d'en-tête ``stdio.h`` on trouvera la ligne : ``int printf( const char *restrict format, ... );``. 
+Nous avons vu au chapitre sur les `prototypes de fonctions <function_prototype>`__ qu'il est possible de ne déclarer que la première ligne d'une fonction. Ce prototype permet au compilateur de savoir combien d'arguments est composé une fonction sans nécessairement disposer de l'implémentation de cette fonction. Aussi on trouve dans tous les fichiers d'en-tête des déclaration en amont (*forward declaration*). Dans le fichier d'en-tête ``stdio.h`` on trouvera la ligne : ``int printf( const char *restrict format, ... );``.
 
 .. code-block::c
 
@@ -201,7 +203,7 @@ Un fichier d'en-tête contiendra donc tout le nécessaire utile à pouvoir utili
 Protection de réentrance
 ------------------------
 
-La protection de réentrence aussi nommée *header guards* est une solution au problème d'inclusion multiple. Si par exemple on défini dans un fichier d'en-tête un nouveau type et que l'on inclus ce fichier, mais que ce dernier est déjà inclu par une autre bibliothèque une erreur de compilation apparaîtera : 
+La protection de réentrence aussi nommée *header guards* est une solution au problème d'inclusion multiple. Si par exemple on défini dans un fichier d'en-tête un nouveau type et que l'on inclus ce fichier, mais que ce dernier est déjà inclu par une autre bibliothèque une erreur de compilation apparaîtera :
 
 .. code-block:: console
 
@@ -242,7 +244,7 @@ La protection de réentrence aussi nommée *header guards* est une solution au p
     ^~~
     ...
 
-Dans cet exemple l'utilisateur ne sait pas forcément que ``bar.h`` est déjà inclus avec ``foo.h`` et le résultat après pré-processing est le suivant : 
+Dans cet exemple l'utilisateur ne sait pas forcément que ``bar.h`` est déjà inclus avec ``foo.h`` et le résultat après pré-processing est le suivant :
 
 .. code-block:: console
 
@@ -260,11 +262,11 @@ Dans cet exemple l'utilisateur ne sait pas forcément que ``bar.h`` est déjà i
     foo(bar);
     }
 
-On y retrouve la définition de ``Bar`` deux fois et donc, le compilateur génère une erreur. 
+On y retrouve la définition de ``Bar`` deux fois et donc, le compilateur génère une erreur.
 
-Une solution à ce problème est d'ajouter des gardes d'inclusion multiple par exemple avec ceci: 
+Une solution à ce problème est d'ajouter des gardes d'inclusion multiple par exemple avec ceci:
 
-.. code-block:: c 
+.. code-block:: c
 
     #ifndef BAR_H
     #define BAR_H
@@ -275,16 +277,16 @@ Une solution à ce problème est d'ajouter des gardes d'inclusion multiple par e
 
     #endif // BAR_H
 
-Si aucune définition du type ``#define BAR_H`` n'existe, alors le fichier ``bar.h`` n'a jamais été inclus auparavant et le contenu de la directive ``#ifndef BAR_H`` dans lequel on commence par définir ``BAR_H`` est exécuté. Lors d'une future inclusion de ``bar.h``, la valeur de ``BAR_H`` aura déjà été définie et le contenu de la directive ``#ifndef BAR_H`` ne sera jamais exécuté. 
+Si aucune définition du type ``#define BAR_H`` n'existe, alors le fichier ``bar.h`` n'a jamais été inclus auparavant et le contenu de la directive ``#ifndef BAR_H`` dans lequel on commence par définir ``BAR_H`` est exécuté. Lors d'une future inclusion de ``bar.h``, la valeur de ``BAR_H`` aura déjà été définie et le contenu de la directive ``#ifndef BAR_H`` ne sera jamais exécuté.
 
 Alternativement, il existe une solution **non standard** mais supportée par la plupart des compilateurs. Elle fait intervenir un pragma :
 
-.. code-block:: c 
+.. code-block:: c
 
     #pragma once
 
     typedef struct Bar {
     int b, a, r;
     } Bar;
 
-Cette solution est équivalente à la méthode traditionnelle et présente plusieurs avantages. C'est tout d'abord une solution atomique qui ne nécessite pas un ``#endif`` à la fin du fichier. Il n'y a ensuite pas de conflit avec la règle SSOT car le nom du fichier ``bar.h`` n'apparaît pas dans le fichier ``BAR_H``. 
+Cette solution est équivalente à la méthode traditionnelle et présente plusieurs avantages. C'est tout d'abord une solution atomique qui ne nécessite pas un ``#endif`` à la fin du fichier. Il n'y a ensuite pas de conflit avec la règle SSOT car le nom du fichier ``bar.h`` n'apparaît pas dans le fichier ``BAR_H``.

content/78-translation-units.rst

@@ -61,7 +61,7 @@ Considérons le programme suivant :
 
 A priori, c'est un programme tout à fait correct. Si l'utilisateur entre le bon mot de passe, il se voit octroyé des privilèges administrateurs. Testons ce programme :
 
-.. code-block:: c
+.. code-block:: console
 
     $ gcc u.c -fno-stack-protector
     $ ./a.out
@@ -71,7 +71,7 @@ A priori, c'est un programme tout à fait correct. Si l'utilisateur entre le bon
 
 Très bien, maintenant testons avec un mauvais mot de passe :
 
-.. code-block:: c
+.. code-block:: console
 
     $ ./a.out
     Password: startrek

content/82-testing.rst

@@ -228,4 +228,178 @@ On voit immédiatement que la partie entière vaut 2, donc 90% de 3.14 donnera u
     inline int16_t q12_mul(int16_t a, int16_t b)
     {
         return q_mul(a, b, 12);
-    }
+    }
+
+Mémoire partagée
+================
+
+Nous le verrons plus loin au chapitre sur la MMU, mais la mémoire d'un processus mémoire (programme) ne peut pas être accedée par un autre programme. Le système d'exploitation l'en empêche.
+
+Lorsque l'on souhaite communiquer entre plusieurs programmes, il est possible d'utiliser différentes méthodes :
+
+- les flux (fichiers, stdin, stdout...)
+- la mémoire partagée
+- les sockets
+
+Vous avez déjà vu les flux au chapitre précédant, et les sockets ne font pas partie de ce cours d'introduction.
+
+Notons que la mémoire partagée est un mécanisme propre à chaque système d'exploitation. Sous POSIX elle est normalisée et donc un programme compatible POSIX et utilisant la mémoire partagée pourra fonctionner sous Linux, WSL ou macOS, mais pas sous Windows.
+
+C'est principalement l'appel système ``mmap`` qui est utilisé. Il permet de mapper ou démapper des fichiers ou des périphériques dans la mémoire.
+
+.. code-block:: c
+
+    void *mmap(
+        void *addr,
+        size_t length, // Taille en byte de l'espace mémoire
+        int prot,      // Protection d'accès (lecture, écriture, exécution)
+        int flags,     // Attributs (partagé, privé, anonyme...)
+        int fd,
+        off_t offset
+    );
+
+
+Voici un exemple permettant de réserver un espace partagé en écriture et en lecture entre deux processus :
+
+.. code-block:: c
+
+    #include <stdio.h>
+    #include <stdlib.h>
+    #include <sys/mman.h>
+
+    void* create_shared_memory(size_t size) {
+        // Accessible en lecture et écriture
+        int protection = PROT_READ | PROT_WRITE;
+
+        // D'autres processus peuvent accéder à cet espace
+        // lequel est anonyme
+        // so only this process and its children will be able to use it:
+        int visibility = MAP_SHARED | MAP_ANONYMOUS;
+
+        // The remaining parameters to `mmap()` are not important for this use case,
+        // but the manpage for `mmap` explains their purpose.
+        return mmap(NULL, size, protection, visibility, -1, 0);
+    }
+
+File memory mapping
+-------------------
+
+Traditionnellement lorsque l'on souhaite travailler sur un fichier, il convient de l'ouvrir avec ``fopen`` et de lire son contenu. Lorsque cela est nécessaire, ce fichier est copié en mémoire :
+
+.. code-block:: c
+
+    FILE *fp = fopen("foo", "r");
+    fseek(fp, 0, SEEK_END);
+    int filesize = ftell(fp);
+    fseek(fp, 0, SEEK_SET);
+    char *file = malloc(filesize);
+    fread(file, filesize, sizeof(char), fp);
+    fclose(fp);
+
+Cette copie n'est pas nécessairement nécessaire. Une approche **POSIX**, qui n'est donc pas couverte par le standard **C99** consiste à lier le fichier dans un espace mémoire partagé.
+
+Ceci nécessite l'utilisation de fonctions bas niveau.
+
+.. code-block:: c
+
+    #include <stdio.h>
+    #include <stdlib.h>
+    #include <sys/mman.h>
+
+    int main() {
+        int fd = open("foo.txt", O_RDWR, 0600);
+        char *addr = mmap(NULL, 100, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+        printf("Espace mappé à %p\n", addr);
+        printf("Premiers caractères du fichiers : %.*s...\n", 20, addr);
+    }
+
+Les avantages de cette méthode sont :
+
+- pas nécessaire de copier l'intégralité du fichier en mémoire ;
+- possibilité de partager le même fichier ouvert entre plusieurs processus ;
+- possibilité laissée au système d'exploitation d'utiliser la RAM ou non si les ressources mémoires deviennent tendues.
+
+Collecteur de déchets (*garbage collector*)
+===========================================
+
+Le C est un langage primitif qui ne gère pas automatiquement la libération des ressources allouées dynamiquement. L'exemple suivant est évocateur :
+
+.. code-block:: c
+
+    int* get_number() {
+        int *num = malloc(sizeof(int));
+        *num = rand();
+    }
+
+    int main() {
+        for (int i = 0; i < 100; i++) {
+            printf("%d\n", *get_number());
+        }
+    }
+
+La fonction ``get_number`` alloue dynamiquement un espace de la taille d'un entier et lui assigne une valeur aléatoire. Dans le programme principal, l'adresse retournée est déréférencée pour être affichée sur la sortie standard.
+
+A la fin de l'exécution de la boucle for, une centaine d'espaces mémoire sont maintenant dans les `limbes <https://fr.wikipedia.org/wiki/Limbes>`__. Comme le pointeur retourné n'a jamais été mémorisé, il n'est plus possible de libérer cet espace mémoire avec ``free``.
+
+On dit que le programme à une `fuite mémoire <https://fr.wikipedia.org/wiki/Fuite_de_m%C3%A9moire>`__. En admettant que ce programme reste résidant en mémoire, il peut arriver un moment où le programme peut aller jusqu'à utiliser toute la RAM disponible. Dans ce cas, il est probable que ``malloc`` retourne ``NULL`` et qu'une erreur de segmentaiton apparaisse lors du ``printf``.
+
+Allons plus loin dans notre exemple et considérons le code suivant :
+
+.. code-block:: c
+
+    #include <stdio.h>
+    #include <stdlib.h>
+
+    int foo(int *new_value) {
+        static int *values[10] = { NULL };
+        static int count = 0;
+
+        if (rand() % 5 && count < sizeof(values) / sizeof(*values) - 1) {
+            values[count++] = new_value;
+        }
+
+        if (count > 0)
+            printf("Foo aime %d\n", *values[rand() % count]);
+    }
+
+    int bar(int *new_value) {
+        static int *values[10] = { NULL };
+        static int count = 0;
+
+        if (rand() % 5 && count < sizeof(values) / sizeof(*values) - 1) {
+            values[count++] = new_value;
+        }
+
+        if (count > 0)
+            printf("Bar aime %d\n", *values[rand() % count]);
+    }
+
+    int* get_number() {
+        int *number = malloc(sizeof(int));
+        *number = rand() % 1000;
+        return number;
+    }
+
+    int main() {
+        int experiment_iterations = 10;
+        for (int i = 0; i < experiment_iterations; i++) {
+            int *num = get_number();
+            foo(num);
+            bar(num);
+            #if 0 // ...
+                free(num) ??
+            #endif
+        };
+    }
+
+La fonction ``get_number`` alloue dynamiquement un espace mémoire et assigne un nombre aléatoire. Les fonctions ``foo`` et ``bar`` reçoivent en paramètre un pointeur sur un entier. Chacune à le choix de mémoriser ce pointeur et de clamer sur ``stdout`` qu'elle aime un des nombre mémorisés.
+
+Au niveau du ``#if 0`` dans la fonction ``main``, il est impossible de savoir si l'adresse pointée par ``num`` est encore utilisée ou non. Il se peut que ``foo`` et ``bar`` utilisent cet espace mémoire, comme il se peut qu'aucun des deux ne l'utilise.
+
+Comment peut-on savoir si il est possible de libérer ou non ``num`` ?
+
+Une solution courament utilsée en C++ s'appelle un *smart pointer*. Il s'agit d'un pointeur qui contient en plus de l'adresse de la valeur, le nombre de références utilisées. De cette manière il est possible en tout temps de savoir si le pointeur est référencé quelque part. Dans le cas ou le nombre de référence tombe à zéro, il est possible de libérer la ressource.
+
+Dans un certain nombre de langage de programmation comme Python ou Java, il existe un mécanisme automatique nommé *Garbage Collector* et qui, périodiquement, fait un tour de toutes les allocations dynamique pour savoir si elle sont encore référencées ou non. Le cas échéant, le *gc* décide libérer la ressource mémoire. De cette manière il n'est plus nécessaire de faire la chasse aux ressources allouées.
+
+En revanche en C, il n'existe aucun mécanisme aussi sophistiqués alors prenez garde à bien libérer les ressources utilisée et à éviter d'écrire des fonctions qui allouent du contenu mémoire dynamiquement.

content/85-data-structures.rst

@@ -1,4 +1,6 @@
 
+.. raw:: latex
+
     \frontmatter
 
 =====================
@@ -17,7 +19,8 @@ Le contenu de ce cours est calqué sur les fiches d'unités de cours et de modul
 - Unité **Informatique 1** (:ref:`Info1 <info1>`)
 - Unité **Informatique 2** (:ref:`Info2 <info2>`)
 
-La version actuelle est |release| générée le |today|.
+La version actuelle : |release|
+Date : |today|
 
 .. raw:: latex