Cela ressemble à un cauchemar de récursion, mais les pointeurs vers des pointeurs sont un élément essentiel de la programmation système. Vous pointez essentiellement vers une adresse mémoire qui contient l’adresse de vos données réelles. Cette indirection à double couche est ce que les développeurs appellent un handle. Ce n’est pas seulement une astuce de codage. Il s’agit d’un mécanisme nécessaire aux systèmes d’exploitation pour gérer efficacement la mémoire tas.
Considérez le tas comme une pièce bondée. Parfois, le système d’exploitation doit déplacer les personnes pour libérer de l’espace. Si vous pointez directement vers quelqu’un, celui-ci ne peut pas bouger sans rompre votre référence. Mais si vous maintenez un pointeur vers une liste de noms, le système d’exploitation peut modifier l’emplacement de toute personne dans cette liste sans que vous ayez besoin de mettre à jour votre référence initiale. C’est le pouvoir d’une poignée.
Voici comment cette logique se traduit en code C brut. Vous déclarez « p » comme pointeur vers un pointeur. Alors « q » devient un pointeur standard. Vous allouez de la mémoire pour « p », puis allouez de la mémoire pour ce vers quoi « p » pointe. Enfin, vous déréférencez deux fois pour attribuer la valeur 12.
Windows et macOS s’appuient sur cette structure pour le compactage de la mémoire. La distinction ici est vitale. Vous, le programmeur, gérez le pointeur externe p. Le système d’exploitation gère le pointeur interne *p. Étant donné que le système d’exploitation contrôle « p », il peut déplacer le bloc de données réel ( *p) n’importe où dans le tas. Il met simplement à jour *p pour refléter la nouvelle adresse. Votre code continue d’utiliser « p » sans accroc.
Au-delà de la gestion de la mémoire du système d’exploitation, ce modèle est essentiel pour transmettre des pointeurs vers des fonctions. Si vous avez besoin d’une fonction pour modifier un pointeur lui-même, vous transmettez un pointeur vers ce pointeur. C’est le seul moyen de réaffecter la référence à partir d’une portée différente.
Gestion des pointeurs vers des structures
La complexité ne s’arrête pas aux simples entiers. Vous pouvez imbriquer cette logique dans des structures. Ceci est courant lors de la gestion de données de longueur variable telles que des chaînes.
Prenez la structure Addr. Il contient des tableaux de taille fixe pour les noms, les villes et les téléphones. Mais la longueur des commentaires varie. Ainsi, « commentaire » est défini comme un pointeur vers char. Lorsque vous allouez de la mémoire pour la structure elle-même, vous réservez de l’espace pour les pointeurs et les tableaux fixes. Vous ne réservez pas encore d’espace pour le texte du commentaire.
Vous attribuez d’abord des « s ». Ensuite, vous lisez les entrées de l’utilisateur dans les tampons fixes. Après cela, vous lisez le commentaire dans un format temporaire
Vous perdez de la mémoire lorsque vous ignorez la façon dont les pointeurs s’imbriquent.
Prenez un pointeur « s » qui pointe vers une structure. Cette structure contient un autre indicateur. Ce deuxième pointeur pointe vers une chaîne réelle en mémoire. Deux couches d’indirection. Une allocation pour la structure. Une allocation pour la chaîne.
Assez simple jusqu’à ce que vous essayiez de nettoyer.
C’est ici que la plupart des développeurs voyagent. Vous voyez « gratuit(s) ». Vous pensez que vous avez terminé. Vous avez tort.
Regardez cet extrait de code :
La variable « s » pointe vers la structure « Addr ». À l’intérieur de cette structure, il y a un champ « commentaire ». comment pointe vers un bloc de mémoire tas alloué pour les données de chaîne.
Lorsque vous appelez « free(s) », vous libérez la mémoire pour la structure elle-même. La structure Addr a disparu. La mémoire est restituée au système.
Mais qu’arrive-t-il à « s->commentaire » ?
Il disparaît dans l’éther.
Le pointeur vers les données de chaîne a été stocké dans la structure que vous venez de libérer. Vous ne pouvez plus y accéder. Vous n’avez pas appelé free() sur la chaîne. La mémoire reste allouée mais inaccessible.
Il s’agit d’une fuite de mémoire.
Ce n’est pas un crash. Ce n’est pas un message d’erreur. Le programme fonctionne bien. Il consomme lentement plus de RAM jusqu’à ce que le système permute ou plante.
Comment réparer les fuites de double pointeur
Vous devez d’abord libérer le pointeur interne. Ou stockez-le dans une variable temporaire avant de libérer la structure externe.
Les données de chaîne sont maintenant publiées. La structure est ensuite libérée. Aucun bloc perdu.
Pourquoi cela arrive si souvent
Les gens traitent les pointeurs comme des valeurs. Ils oublient que les pointeurs sont des références à des ressources.
Lorsqu’une structure contient un pointeur, cette structure n’est pas autonome. Il s’appuie sur une mémoire externe. Libérer le conteneur ne libère pas le contenu.
Cela empire avec une nidification plus profonde. Un pointeur vers un pointeur vers un pointeur. Trois niveaux. Vous avez besoin de trois appels free(). Dans le bon ordre.
Si vous en oubliez un, vous fuiez.
Le problème de gets()
L’exemple utilise gets(). Cette fonction est dangereuse. Il a été supprimé de la norme C11 car il autorise les débordements de tampon. Mais la logique de la mémoire reste la même.
Que vous utilisiez gets(), fgets() ou scanf(), la stratégie d’allocation est ici le goulot d’étranglement des fuites.
Vous allouez pour s.
Vous allouez pour s->comment.
Si vous ne libérez que les « s », vous laissez « s->comment » derrière.
Points clés à retenir
- Les pointeurs doubles nécessitent un double gratuit.
- Vérifiez chaque « malloc » pour un « gratuit » correspondant.
- Si une structure contient un pointeur vers la mémoire dynamique, cette mémoire doit être libérée avant la structure.
free()ne libère pas les membres de manière récursive.
Il est facile de rater. Le code se compile. Ça marche. La fuite est silencieuse.
Jusqu’à ce que ce ne soit pas le cas.
Création de listes liées
Vous pouvez vous retrouver avec un désastre de mémoire si vous supprimez le conteneur avant les données vers lesquelles il pointe. La structure contenant le pointeur est nettoyée. Le bloc de chaîne reste. Cela devient un bloc perdu. Cela se produit lorsque l’ordre d’élimination est erroné.
Lien
Les structures peuvent pointer vers elles-mêmes. Cela vous permet d’enchaîner des enregistrements identiques. Le résultat est une liste chaînée. C’est une manière standard d’organiser les données en C.
Voici comment vous le définissez :
typedef struct { nom de caractère[21]; ville de char[21]; état de caractère[21] ; Adresse suivant ; } Adresse ;
Adresse en premier ;
Le champ « suivant » contient l’adresse de l’enregistrement suivant. Vous utilisez une seule variable de pointeur pour démarrer la chaîne.
Le coût de la flexibilité
Le compilateur vous permet de contourner des règles qui peuvent sembler contre-intuitives à première vue. Avec suffisamment d’expérience, vous pouvez concevoir des structures qui ressemblent à celle illustrée ci-dessus. C’est un mouvement de pouvoir.
Mais ce n’est pas sans risque. Vous marchez sur une ligne fine entre un code intelligent et des spaghettis impossibles à maintenir.
Pourquoi c’est important
Ce n’est pas seulement une question de syntaxe. Il s’agit de ce que le langage vous permet de faire lorsque vous repoussez ses contraintes.
- Contrôle : vous bénéficiez d’un contrôle granulaire sur la disposition de la mémoire.
- Interopérabilité : Vous pouvez communiquer plus facilement avec les bibliothèques C.
- Performance : Parfois, le contournement des contrôles de sécurité permet d’économiser des cycles.
Le piège ? Le compilateur ne vous sauvera pas de vous-même. Il vous permettra de compiler du code qui plante au moment de l’exécution.
Comment l’utiliser en toute sécurité
Si vous comptez faire cela, faites-le avec intention.
- Isolez-le : ne diffusez pas ce modèle dans votre base de code. Conservez-le dans un petit module bien testé.
- Documentez tout : L’avenir, vous remercierez de vous présenter. Ou te détester. Je te déteste probablement.
- Utilisez des abstractions : enveloppez les pointeurs bruts ou les blocs non sécurisés dans une interface propre. Cachez le désordre.
Le test de la réalité
La plupart des développeurs n’en ont pas besoin. Ils utiliseront des structures standards. Ils en seront plus heureux.
Mais lorsque vous vous heurtez à un mur où la bibliothèque standard ne rentre pas, vous serez heureux que le compilateur ne vous ait pas arrêté.
La question est de savoir si vous êtes prêt à payer les frais d’entretien.
C’est un compromis. La vitesse pour la sécurité. Le pouvoir pour la clarté.
Vous choisissez.
