Leçon 7 : Le cauchemar du programmeur

Le contenu de la variable monHandle (si l'opération a réussi) est une adresse en mémoire (en rouge dans le tableau). Les adresses-mémoire sont codées sur des entiers longs (occupant 4 octets) représentées généralement en valeurs hexadécimales.

À l'adresse trouvée dans la variable handle est rangée une autre adresse-mémoire (en bleu dans le tableau). Cette autre adresse indique le début du bloc en mémoire où l'on peut retrouver les octets qui composent notre chaîne.

Pour un débutant, travailler avec les handles est beaucoup plus périlleux. L'expérience est cependant grisante, mais c'est comme si on jouait dans la cour des grands, l'espace est plus grand mais les contacts plus rugueux. Une erreur vous conduit très rapidement au crash du programme quand ce n'est pas de la machine toute entière. Le mécanisme est pourtant très éprouvé et en suivant les règles de bonne conduite, il n'y a aucune raison que les choses se passent mal.

Lorsqu'on utilise les handles, on doit collaborer avec le Memory Manager qui a de son côté d'importantes tâches à régler.

Une des règles essentielles est de toujours s'informer auprès du Memory Manager pour savoir s'il a pu faire son travail dans de bonnes conditions. Lorsqu'on lui demande de réserver un bloc en mémoire, on doit toujours s'inquiéter de savoir si notre requête a abouti avant de faire quoi que se soit. La plupart des appels à la Toolbox qui retournent des handles, renvoient la valeur 0 quand l'opération a échoué, la vérification dans ce cas-là consiste à tester la valeur de notre variable handle, si elle est non nulle nous avons alors obtenu un bloc valide, si elle est nulle, cela signifie dans la majorité des cas que la mémoire est saturée et que le bloc n'a pu être alloué, et bien sûr notre programme doit alors prendre les mesures qui s'imposent.

Vous verrez très souvent dans les extraits de code que vous étudierez le genre de séquence suivante :

DIM monHandle AS HANDLE
monHandle = FN NewString("Hello")

LONG IF monHandle <> _nil
// On a obtenu le handle
XELSE
// Le handle n'a pu être créé
END IF

Dans une situation d'échec, souvent due au manque d'espace-mémoire disponible, on peut vouloir informer l'utilisateur du problème rencontré, afin de lui suggérer des mesures à prendre, comme quitter le programme pour augmenter, dans le Finder, la mémoire allouée à l'application. Un problème peut cependant survenir ici, car vous pourriez ne pas avoir suffisamment de mémoire disponible pour afficher même ce type d'information. Certains programmeurs ont pris l'habitude d'allouer au démarrage de leur programme un bloc tampon suffisamment grand pour régler cette possible difficulté et lorsque la mémoire vient à manquer, ils libèrent ce bloc pour permettre l'affichage du message d'alerte. D'autres programmeurs évaluent l'espace disponible avant d'exécuter des fonctions dont ils savent qu'elles vont réclamer une bonne quantité de mémoire.

À la différence des variables traditionnelles qui sont créées et détruites grâce au code généré par le Compilateur, les handles sont gérés par le Memory Manager et par le programmeur. Le Memory Manager essaie de rentabiliser au mieux l'espace-mémoire alloué à votre application, si par exemple l'espace vient à manquer pour réserver ou agrandir un bloc, il va réorganiser les blocs relogeables de telle sorte qu'ils soient contigus en mémoire éliminant ainsi les espaces entre les blocs qui sont inutilisés (on verra aussi qu'il peut être autorisé à retirer de la mémoire certains blocs momentanément inutiles). Si ce compactage ne permet toujours pas de réserver le bloc, le Memory Manager vous signalera l'erreur rencontrée soit en retournant un handle nul, soit en positionnant un code d'erreur que vous pouvez consulter grâce à la fonction de la Toolbox MemError. Lorsque le Memory Manager déplace un bloc, il met à jour le pointeur qui le référence de telle sorte que l'adresse indiquée reflète le nouvel emplacement du bloc en mémoire. Ce mécanisme est parfaitement rôdé, mais il peut vous conduire à commettre des erreurs fatales à votre application. Considérez l'exemple suivant :

DIM monHandle   AS HANDLE
DIM autreHandle AS HANDLE
DIM monPointeur AS POINTER

monHandle = FN NewHandle(100000)
LONG IF monHandle
  monPointeur = [monHandle]
  autreHandle = FN NewHandle(100000)
  LONG IF autreHandle = _nil
    PRINT "Mémoire insuffisante !"
  END IF
  & monPointeur, 1215
XELSE
  PRINT "Mémoire insuffisante !"
END IF

Le code ci-dessus contient un bug parfois difficile à traquer, car il peut fonctionner très longtemps avant qu'un imprévu ne survienne.

Un nouvel handle est demandé au Memory Manager pointant sur un bloc de 100000 octets. Si l'opération a réussi, le code extrait l'adresse du bloc relogeable avec, ici, le raccourci utilisant les crochets (on aurait pu utiliser une syntaxe plus classique avec la fonction PEEK LONG qui retourne un entier long depuis l'adresse-mémoire qui lui est passée en paramètre). Lorsqu'on extrait le pointeur d'un handle, on dit que l'on déréférence le handle.

Ensuite un autre handle de 100000 octets est réclamé au Memory Manager. Enfin, un entier long ayant pour valeur 1215 est rangé dans le premier bloc mémoire alloué. Là encore on aurait pu utiliser la syntaxe plus classique POKE LONG.

Un problème peut survenir lorsque le Memory Manager voudra allouer le second bloc : si la mémoire n'est pas suffisante, il va procéder à des déplacements de blocs relogeables y compris le bloc réservé pour notre premier handle, si bien que notre variable appelée monPointeur qui contient une copie de l'adresse originale, ne contiendra plus l'adresse valide pour retrouver notre premier bloc. L'écriture en mémoire de la valeur 1215 peut alors avoir des conséquences fâcheuses, qui sait ce que peut contenir cette zone mémoire à cet instant ?

Pour éviter ce genre de désagrément on peut verrouiller le bloc à l'aide de la procédure de la Toolbox HLock (le Memory Manager ne déplace pas les blocs qui lui sont signalés comme verrouillés). Moralité, si vous devez déréférencer un handle, faites-le une fois que le bloc aura été verrouillé en mémoire. Il est recommandé également de garder ses blocs verrouillés le moins longtemps possible pour que le Memory Manager puisse travailler confortablement.

La manipulation des handles vous oblige à adopter des stratégies. L'exemple prétexte proposé pourrait éventuellement s'écrire de la manière suivante afin de sécuriser au maximum les traitements :

DIM monHandle   AS HANDLE
DIM autreHandle AS HANDLE
DIM monPointeur AS POINTER

monHandle = FN NewHandle(100000)
LONG IF monHandle
  autreHandle = FN NewHandle(100000)
  LONG IF autreHandle = _nil
    PRINT "Mémoire insuffisante !"
  END IF
  HLock(monHandle)
  LONG IF FN MemError = _noErr
    monPointeur = [monHandle]
    & monPointeur, 1215
  END IF
  HUnlock(monHandle)
XELSE
  PRINT "Mémoire insuffisante !"
END IF

Vous pourriez aussi bien écrire ceci :

DIM AS HANDLE monHandle,autreHandle

monHandle = FN NewHandle(100000)
LONG IF monHandle
  autreHandle = FN NewHandle(100000)
  LONG IF autreHandle = _nil
    PRINT "Mémoire insuffisante !"
  END IF
  & [monHandle], 1215
XELSE
  PRINT "Mémoire insuffisante !"
END IF

Notez également que lorsque vous écrivez ceci :

autreHandle = monHandle

Vous copiez simplement l'adresse contenue dans la variable monHandle dans la variable autreHandle, en aucun cas vous n'avez dupliqué les données contenues dans le bloc relogeable référencé. Vous avez en quelque sorte créé un alias de votre handle original, mais attention, cet alias restera valide pour autant que le Memory Manager ne déplace pas le bloc original, car n'ayant pas été directement sollicité, il n'a aucun moyen de savoir que votre code a dupliqué l'adresse contenue dans une variable handle et il ne mettra donc pas à jour cette copie si le bloc référencé venait à être déplacé.

Pour dupliquer un handle avec ses données vous pouvez soit  :