Mokona Guu Center

Les tableaux automatiques

Publié le

Avant-hier, je lisais un vieux livre sur l'art et la manière d'utiliser son Commodore 64. « Utiliser », à l'époque des ordinateurs familiaux, cela incluait pratiquement tout le temps la programmation en Basic. Arrivé à cette partie, je tombe sur un passage qui me fait rire, d'autant plus que, en effet, je me souviens tout à coup que cela fonctionnait comme ça.

Alors, attention, si vous n'êtes pas informaticien, si vous n'avez jamais fait de Basic à l'époque des ordinateurs familiaux, je vous préviens, le rire ne vient pas facilement.

Le passage indique que lorsque l'on utilise pour la première fois un tableau, on peut se passer d'un DIM (allocation du tableau) si l'indice est inférieur ou égal à 10. Dans ce cas, un DIM de taille 10 est implicitement fait, entraînant par là la création d'un tableau de onze cellules.

Du coup, hier, j'ai fait une petite recherche dans d'autres vieux livres. Effectivement, sur Oric, Amstrad CPC, Basic Omikron (je n'ai pas retrouvé pour le GFA Basic), on retrouve cette même règles. Cela n'est pas précisé dans le livre sur le ZX Spectrum que j'avais sous la main. Une petite recherche (entre autre sur Wikipedia, où j'ai découvert un OVNI) ne m'a pas permis de savoir si ce comportement était une norme ou juste une convention de l'époque. Les Basic actuels (comme Pure Basic, Dark Basic) ne me semblent pas fonctionner comme cela, mais je ne suis pas non plus un spécialiste.

Pourquoi ce rire ? Il y a deux choses qui chiffonnent dans cette allocation automatique.

Tout d'abord, pourquoi ce cas particulier ? Peut-être parce qu'on parle ici du Basic, le langage que tout le monde pouvait apprendre, que les variables n'avaient pas besoin d'y être définies mais que néanmoins, dans le cas d'un tableau, il est plus facile de fixer une taille d'un point de vue implémentation (à l'époque, le REDIM, permettant de redimensionner un tableau sans destruction des données des cellules qui restent est un luxe). Un mélange de contraintes techniques et d'offre de facilité donc.

Ensuite, pourquoi 11 ? Pourquoi pas 8, qui est naturellement plus informaticien, ou 42 (The Hitchhiker's Guide to the Galaxy date de 1979, mais ici, la réponse est évidente, 42, c'est trop gros). Je suppose que 11 parce que 10. DIM A(10) créé sur la plupart des BASIC un tableau de taille 11, car l'argument passé n'est pas la taille du tableau, mais le plus grand index utilisable, les index commençant à zéro. Ça encore, c'est un point qui m'a fait rire, surtout en me souvenant que ces histoires d'index me posaient de réels soucis à l'époque.

Cela devait choquer d'autres personnes d'ailleurs car j'ai relevé dans ma recherche d'hier que certains Basic indexaient à partir de 1 jusqu'à l'indice passé, que d'autres demandaient de préciser les bornes inférieures et supérieures, et que d'autres indexaient de zéro à l'index maximum moins un.

Je n'ai donc pas d'autre explication, mais je suis preneur ; taille 11 car DIM A(10) et que 10 est un chiffre rond (pas pour un informaticien, mais c'est une autre histoire).

Plus de vingt ans après, ce manque de rigueur me fait rire. Mais cela me rappelle aussi que cette attitude (utilisation d'un nombre arbitraire, comportement automatique ou pas suivant l'utilisation) n'a pas disparu des habitudes de certains programmeurs.