Exceptionnellement, nous allons quitter le ton formel et sentencieux habituel pour une petite digression. Au sujet de cette noble activité qu’est le codage, qui compte autant d’églises que de croyants. Luttons contre une idée reçue : ceux qui préfèrent des langages incorporant nativement un ramasse-miette ne sont pas des sous-hommes qui ne connaissent rien à la vie. Vous aurez toutes les chances d’entendre cet argument modéré et cordial en écoutant deviser sereinement un codeur C et un codeur Java par exemple. Ce qui n’empêche pas que les codeurs Java sont des sous-hommes, ne me faites pas dire ce que je n’ai pas dit.
Au nom de quel principe aligner des lignes de malloc et de free confèrerait un savoir particulier aux codeurs C ? Sincèrement ? D’abord, la plupart des codeurs C font surtout des allocations. Désallouer est un problème mineur au vu des quantités de RAM disponibles aujourd’hui. Mais soit. Imaginons un codeur C qui fasse aussi de belles désallocations à point nommé. Genre, ça existe. Comment va-t-il soi-disant gérer sa mémoire ? Il va allouer dès qu’il en aura besoin, fera son traitement, et désallouera aussi sec. Une belle mémoire toute morcelée. C’était bien la peine de la ramener avec ses instructions bas niveau tiens. Pondre un beau modèle de gestion mémoire n’est pas donné au premier venu, et rarement adressé.
Deuxièmement, bénéficier d’un ramasse-miette ne dispense pas de gérer la mémoire. Généralement, ceux qui font du C++ un peu poussé l’ont compris, même si en contrepartie, ils continuent de faire du C++ alors que c’est quand même le langage le plus alambiqué du monde. Les nazes. Et dire que les mecs qui font du C++ raillent ceux qui font du Java. On marche sur la tête franchement. Faisons un pari : donnez à votre codeur C++ à écrire une classe Matrice qui implémente une addition. Que va-t-il vous pondre à votre avis ? Un bel opérateur ‘+’ qui renvoit une instance temporaire de Matrice ! Vous me devez 100€. Je n’ai aucun mérite, c’était prévisible. Votre petit codeur C++ vient de vous morceler la mémoire, il ne s’en est même pas rendu compte : ses habitudes de codeur C lui collent à la peau. Donnez la même chose à faire à un codeur Java : même constat, ce qui monte votre ardoise à 200€. Celui-là ne vous morcelle pas forcément la mémoire, par contre il court à corps perdu vers le seuil qui déclenchera le ramasse-miette en saturant la mémoire disponible d’instances temporaires. Adieu veau, vache, cochon, performances, temps de réponse et client satisfait. Que fallait-il faire ? Une méthode d’addition à trois arguments qui ne fera que l’addition stricto sensu. Charge à l’utilisateur de gérer les allocations/désallocations au préalable. C’est moins beau, soi-disant moins lisible, mais au moins ça marche, et permet à l’utilisateur de gérer la mémoire s’il le veut.
Qu’avons-nous appris aujourd’hui ? Que rares sont ceux qui comprennent ce qu’implique la notion de gestion mémoire, mais que beaucoup croient le savoir. Ce qui laisse entrevoir toute une perspective de discussions stériles entre gens butés : j’adore !