Pk
4 unresolved threads
4 unresolved threads
Compare changes
+ 20
− 12
@@ -127,15 +127,17 @@ booléen est_dans_page(page, valeur) // la valeur est dans la page
@@ -127,15 +127,17 @@ booléen est_dans_page(page, valeur) // la valeur est dans la page
@@ -157,6 +159,7 @@ page nouvelle_page(ordre)
@@ -157,6 +159,7 @@ page nouvelle_page(ordre)
@@ -183,7 +186,7 @@ page recherche(page, valeur) // retourner la page contenant
@@ -183,7 +186,7 @@ page recherche(page, valeur) // retourner la page contenant
@@ -202,9 +205,11 @@ page inserer(page, valeur) // inserer une valeur
@@ -202,9 +205,11 @@ page inserer(page, valeur) // inserer une valeur
@@ -213,7 +218,8 @@ page inserer(page, valeur)
@@ -213,7 +218,8 @@ page inserer(page, valeur)
@@ -225,7 +231,7 @@ rien inserer_element(page, element)
@@ -225,7 +231,7 @@ rien inserer_element(page, element)
@@ -241,13 +247,15 @@ rien placer(page, element) // inserer un élément
@@ -241,13 +247,15 @@ rien placer(page, element) // inserer un élément
ah non mais je suis con comme un balais. il manque un
si est_dans_page(page, element.clef) retourne
dans placer. Ensuite je pense que c'est ok. Comme ça on modifie pas l'argument de placer. Tu en dis quoi?
Edited by orestis.malaspinBaaa pas sur. Il y a des appels recursifs à inserer_element qui vont aboutir sur un placer. Dans ce placer, il se peut qu'on scinde et qu'on se retrouve avec un element.page != vide (élément promu). Il faut alors le placer après le retour de inserer_element. Mais pour les autres appels à inserer_element qui restent empilés ? il faut leur signaler qu'il ne faut pas faire de placer (element va pointer sur l'élément qui a été promu plus bas dans l'arbre).
@@ -266,7 +274,7 @@ rien scinder(page, element)
@@ -266,7 +274,7 @@ rien scinder(page, element)
@@ -285,7 +293,7 @@ page ajouter_niveau(page, element) // si on remonte à la racine...
@@ -285,7 +293,7 @@ page ajouter_niveau(page, element) // si on remonte à la racine...
c'est au cas où l'allocation de élément a merdé?
sinon jevois pas pourquoi avoir si element != vide