IFT2030 Langages de programmation TP3 par: Nicola

IFT2030
Langages de programmation
TP3
par:
Nicola Grenon GREN30077303
et
Jean-François Delisle DELJ02057809
lundi dix-sept avril deux mille six

I – Le fonctionnement des programmes.
Les deux programmes que nous avons écrits sont basés sur un schème
similaire. Les principales différences structurelles, mis à part évidemment ce que
nécessite la syntaxe du langage, concernent surtout la structure de données sous-
jacente à la mémorisation des données. Là où le programme en C utilise des listes
simplement chaînées, le programme en Java utilise lui des LinkedList, simplement
parce que la structure était déjà disponible, simple d'utilisation tout en ayant une
similitude avec notre liste simplement chaînée intéressante. Mais au niveau des objets
Java ou des struct de C, la forme est identique.
Ainsi, la parcelle d'information de base dans les deux environnements est la
Chaîne définie comme contenant un string (au sens de suite de caractères) et un
compteur de multiplicité. Chaque fois qu'on voudra ajouter une chaîne de caractère à
notre base de données, on vérifiera donc si elle est déjà présente dans la liste de toutes
celles déjà employées et si c'est le cas, on incrémentera simplement le compteur au lieu
d'en allouer une nouvelle. De même, au moment d'en effacer une, on vérifiera si la
multiplicité de celle-ci est supérieure à 1 avant de l'effacer complètement.
Les individus de l'annuaire quant à eux se trouvent à n'être que des structures
vides contenant uniquement des pointeurs/références vers les chaînes précédemment
stockées. Il est à noter qu'on pourrait être tenté en Java de ne pas conserver de
compteur dans la structure de la chaîne puisque de toute façon tant que l'élément est
référencé il est conservé et dès qu'il ne l'est plus il est libéré. Or on s'aperçoit que parce
qu'on a besoin de conserver dans une liste (...) les éléments afin de savoir si on a
besoin de créer ou pas la nouvelle chaîne (ou d'en retrouver l'adresse mémoire) celle-ci
resterait donc indéfiniment active si on ne savait pas quand l'exclure justement de ladite
liste.
Le problème qu'il reste à prévoir en C surtout est la lecture de l'information à
partir de la console. Comme on ne sait pas à l'avance la longueur de la chaîne de
caractère qui sera reçue, on doit donc la lire petit à petit, en affectant, par petit bloc
d'espace, à nouveau dans une liste chaînée, les caractères lus. À la fin de la lecture
d'une chaîne, l'adresse de celle-ci sera finalement stockée dans la liste des struct
chaine.

Voici trois petits diagrammes précisant la façon dont sont gérées les données
dans notre programme C. La structure en Java est très proche pour les deux premiers,
mais emploie deux LinkedList plutôt que des listes simplement chaînées.
dummy
liste NULL
n n n
NULL
sss
Structure de la liste des chaînes
n: multiplic ité
s: texte
dummy
annuaire NULL
NULL
Structure de l'annuaire des individus
nom num rue ville nom num rue ville nom num rue ville
Individus
Pointeurs vers des éléments de la liste des chaînes ...
debut NULL
c
Structure de la liste chaînée (blocs) employée pour la lecture du stdin
c: *char
c cc

II – Comparaison des styles de programmation.
La principale différence au niveau de la programmation entre les deux langages
est bien entendu le haut niveau d'abstraction, permis par Java et les classes prédéfinies
accessibles, comparativement à C. Bien sûr en C nous aurions sans doute pu tirer
avantage de plus d'outils déjà prêts, mais il reste que dans l'ensemble, Java permet
souvent d'exprimer au moyen d'une simple instruction ce qui nécessite en C plusieurs
lignes de code.
L'encapsulation du Java permet également une synthétisation et un groupement
des informations qui rend la relecture du code beaucoup plus aisée.
La gestion simplifiée des exceptions est aussi un incontournable. Dans le code
du programme en C, le nombre de lignes que l'on est obligé d'ajouter pour gérer
simplement les dépassements de mémoire est effarant. À chaque lecture de la console,
on doit tester le retour, à chaque allocation d'un maillon de chaîne on doit tester le
retour et à chaque allocation d'un élément de nos chaînes on doit tester le retour... sans
compter les tests sur les retours eux-mêmes si on n'est pas déjà dans le main!
Et en elle-même, la gestion automatisée du collecteur d'espace mémoire inutilisé
(garbage collector) rend aussi caduque une bonne partie du code qui est nécessaire en
C.

2.1) Les chaînes de longueur quelconque.
Le problème de la lecture des chaînes de longueur quelconque en est un
du paradoxe de l'œuf ou de la poule... Pour savoir combien allouer de mémoire à
la structure de donnée qui contiendra ladite chaîne, il faudrait d'abord en
connaître la taille finale... ce qu'on ne saura qu'une fois la chaîne complètement
lue... et donc déjà stockée. Comme on est en l'absence d'une structure qui
s'ajuste automatiquement selon le besoin, on a donc élaboré une stratégie de
«morcelage». On a choisit de lire les sections de la chaîne petit bout par petit
bout en les concaténant ensuite via une liste chaînée. On perd un peu d'espace
dans le processus (pointeurs chaînant) et on a ensuite le choix entre traîner cette
structure complexe ou la transférer dans une seule grande chaîne de caractère
de la bonne longueur... nécessitant au passage des opérations coûteuses en
espace ou en temps de calcul.
La fonction Java elle permet de se libérer de cette complexité en faisant ce
genre de gestion de façon automatique.
2.2) Le partage des chaînes / la récupération de l'espace utilisé.
Notre solution au partage des chaînes utilise la même tactique dans les
deux cas. Nous en avons déjà discuté plus haut, mais il s'agit en résumé que la
structure ou l'objet définissant un individu (et donc ses informations) ne soit qu'un
registre de références à des éléments existants ailleurs, dans une liste qui elle
gère l'ensemble de toutes les chaînes connues et le compte du nombre de fois
que chacune est utilisée. Il ne nous reste alors plus qu'à incrémenter ou