Dans un programme comme Ruby, Java ou autre, c'est au programmeur de gérer la mémoire lui même. C'est juste que 97% du travail est automatisé. Pour libérer un objet en mémoire il suffit de le déréférencer. Biens ur on peut accélérer les choses avec un destroy() quelconque mais généralement le simple fait de détruire les références vers l'objet suffit à faire que le garbage collector fera le ménage tout seul.
Ca marche très très bien.
En C c'est plus compliqué. Il faut spécifiquement libérer toute la mémoire que l'on a consommé. C'est long, c'est réberbatif, c'est casse pied et si on oublie quelquechose ca peut trainer en mémoire jusqu'à la fermeture du programme.
Le SEUL avantage de l'accès mémoire direct au point de vue programatique (ie si on considère le surcout en mémoire du GC comme négligeable) est dans un cas bien précis :
Si on objet a un accès passif à une ressource système (par exemple il écoute sur un port X)
- En C : je sors le fusil à pompe, pan -> objet détruit. Je peux immédiatement relancer un autre objet sur le port X
- En programmation GC : Je sors le pot de peinture rouge et je peints une jolie croix sur le dos de mon objet. Si j'essaye de relancer immédiatement un autre objet sur le port X je risque de me prendre une erreur de type "t'es mignon, mais le port X est occupé". Tout çà parceque le GC il dort, ou qu'il est déjà en train de donner des coups de fusil à pompe ailleurs. Je suis donc dépendant de son bon vouloir.
# Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 7.
Ca marche très très bien.
En C c'est plus compliqué. Il faut spécifiquement libérer toute la mémoire que l'on a consommé. C'est long, c'est réberbatif, c'est casse pied et si on oublie quelquechose ca peut trainer en mémoire jusqu'à la fermeture du programme.
Le SEUL avantage de l'accès mémoire direct au point de vue programatique (ie si on considère le surcout en mémoire du GC comme négligeable) est dans un cas bien précis :
Si on objet a un accès passif à une ressource système (par exemple il écoute sur un port X)
- En C : je sors le fusil à pompe, pan -> objet détruit. Je peux immédiatement relancer un autre objet sur le port X
- En programmation GC : Je sors le pot de peinture rouge et je peints une jolie croix sur le dos de mon objet. Si j'essaye de relancer immédiatement un autre objet sur le port X je risque de me prendre une erreur de type "t'es mignon, mais le port X est occupé". Tout çà parceque le GC il dort, ou qu'il est déjà en train de donner des coups de fusil à pompe ailleurs. Je suis donc dépendant de son bon vouloir.