Vous souhaitez créer un éditeur de texte. Il s’agit peut-être d’un remplacement moderne de Vi ou d’une nouvelle version du Bloc-notes. Cela n’a pas d’importance. L’objectif est simple : permettre aux utilisateurs d’éditer des fichiers ASCII standard.
Pensez à la fréquence à laquelle les programmeurs utilisent réellement ces outils. C’est leur principale interface avec la machine. C’est là que les pensées deviennent du code. Naturellement, vous voulez que vous vous sentiez bien. Vous voulez que ce soit rapide. Vous souhaitez qu’il gère votre flux de travail spécifique. Alors, vous décidez de construire le vôtre.
Le premier obstacle est la structure des données. Comment stocker le texte en mémoire ? Vous avez besoin d’un moyen de manipuler les personnages rapidement. Votre premier réflexe ? Lignes de texte.
Vous prenez un tableau. Assez simple. Une ligne typique comporte 80 caractères. Un fichier typique contient peut-être 1 000 lignes. Vous déclarez un tableau à deux dimensions :
Cela fait 80 000 caractères. Maniable. Faire le ménage.
Mais voilà que la réalité nous frappe. Vous pensez aux cas extrêmes.
Certains fichiers sont des listes de journaux volumineuses. Des milliers de lignes, chacune d’à peine 10 caractères.
D’autres fichiers sont des sauvegardes de données à usage spécial. Une ligne peut contenir 542 caractères représentant des paires d’acides aminés dans une séquence d’ADN.
Et les éditeurs modernes vous permettent d’ouvrir plusieurs fichiers simultanément. Disons que vous le limitez à 10 fichiers ouverts. Vous définissez une limite stricte de 1 000 caractères par ligne et de 50 000 lignes par fichier.
Maintenant, votre déclaration ressemble à ceci :
Vous calculez les chiffres. 50 000 fois 1 000 fois 10. Cela fait 500 millions de caractères.
La plupart des ordinateurs ne peuvent pas gérer cela. Même avec de la mémoire virtuelle, c’est une contrainte. Exécutez trois instances de votre éditeur sur un système multi-utilisateurs et vous étouffez la RAM. C’est un gaspillage extravagant. Vous allouez de l’espace pour le pire des cas, lorsque la plupart des utilisateurs se contentent de modifier des fichiers de 100 lignes occupant 4 000 octets.
Le problème avec les tableaux est rigide. Vous devez déclarer à l’avance la taille maximale dans chaque dimension. Ces dimensions se multiplient. Et si quelqu’un essayait d’ouvrir un fichier contenant une ligne de 2 000 caractères ? Vous n’avez pas de chance. La longueur de la ligne est techniquement infinie. Vous ne pouvez pas le prédire.
C’est pourquoi les pointeurs existent.
Comment les pointeurs résolvent le gaspillage de mémoire
Les pointeurs vous permettent de créer des structures de données dynamiques. Au lieu de réserver de l’espace statique à l’avance, vous allouez de la mémoire à partir du tas pendant l’exécution du programme.
Vous utilisez la quantité exacte de mémoire dont le document a besoin. Pas de gaspillage. Lorsque vous fermez un fichier, vous remettez cette mémoire dans le tas. D’autres parties du programme peuvent l’utiliser. La mémoire est recyclée.
Il ne s’agit pas seulement d’économiser de l’espace. C’est une question de flexibilité. Vous n’avez pas besoin de deviner la longueur maximale de la ligne. Vous allouez ce dont vous avez besoin, quand vous en avez besoin.
Si vous vous demandez encore ce qu’est réellement un octet, ou comment « méga » et « giga » se traduisent en contraintes du monde réel, lisez des informations sur les bits et les octets. Alors reviens. Vous devrez comprendre les limites matérielles pour comprendre pourquoi les tableaux statiques échouent ici.
