WINDEV et le Garbage Collector

Définition.
Le garbage collector (GC) est le “ramasse-miettes” de WINDEV : il récupère automatiquement la mémoire des objets qui ne sont plus référencés. Il travaille en arrière-plan et son passage est non déterministe (tu ne choisis pas l’instant exact). Quand un objet est détruit, son destructeur s’exécute.

Pourquoi c’est utile.

Moins d’erreurs liées à la mémoire, plus de productivité.
Allocation/libération automatiques pour les données purement en RAM (chaînes, tableaux, structures…).

Limites à connaître.

Des pauses ponctuelles peuvent survenir.
Le GC ne gère pas tes ressources externes : fichiers, requêtes HFSQL, sockets, imprimante, objets graphiques, etc.
Un objet non référencé peut rester quelque temps en mémoire jusqu’au prochain passage du GC.

Ce que le GC ne fait pas (donc ce qui dépend de toi).

Fermer un fichier et lever un verrou disque.
Relâcher une requête/connexion HFSQL côté client/serveur.
Couper une socket ou une ressource réseau.
Nettoyer des secrets (token, mot de passe) stockés en mémoire.

Bonne stratégie (mental model).

GC = mémoire, toi = ressources.
Le destructeur est l’endroit pour fermer/relâcher les ressources externes de l’objet.
Si tu veux que ce nettoyage arrive immédiatement (ex. lever un verrou fichier juste après usage), déclenche la destruction de l’objet depuis l’appelant afin que le destructeur s’exécute tout de suite, au lieu d’attendre le GC.

Quand libérer tout de suite ?

Ressources bloquantes (fichiers ouverts, transactions, curseurs).
Ressources rares/coûteuses (connexions réseau, gros buffers graphiques).
Boucles et sections critiques où la latence compte : on relâche à chaque itération.

Quand laisser au GC ?

Données pures en mémoire sans effet de bord (objets de courte durée, temporaires).
-Cas non sensibles aux verrous ni à la latence.

Bonnes pratiques WINDEV.

Ownership clair : une ressource a un propriétaire (souvent une classe) et son destructeur la ferme.
Durée la plus courte possible : ouvrir tard, fermer tôt.
Couper les références inutiles (éviter les globales qui “retiennent” un objet).
Journaux de diagnostic : tracer “ouvert/fermé” pour visualiser la durée de vie.
Secrets : effacer le membre sensible avant destruction si tu en conserves.

Anti-patterns (à éviter).

Attendre “que le GC passe” pour lever un verrou.
Centraliser trop de ressources dans un objet longue durée.
“Vider l’objet” dans le destructeur ou tenter de s’auto-détruire depuis celui-ci : inutile, voire risqué.
Chercher à “piloter” le GC : la bonne approche est la libération déterministe des ressources.

----------------------------------
*Lien de vidéo
   • WINDEV et le Garbage Collector