Dans mes programmes, je suis toujours embété par la gestion des
désallocation d'objets lorsque survient une erreur quelconque...
par exemple, lors de la construction d'un objet important pour le
programme, il y a échec, je dois détruire tous les objets créés
auparavant afin de quitter proprement.. celà demande toujours des tests
ennuyeux, et de plus, la liste de ces objets à détruire n'est jamais la
même suivant l'endroit du programme où l'erreur survient.
J'ai donc dans l'idée de programmer un petit gestionnaire d'erreur, je
pensais à un objet qui contiendrait la liste des objets crées
(pointeurs) ainsi qu'un pointeur vers leur destructeur respecif et un
message char* approprié (tel que le nom etc...)
ainsi lors d'une erreur, il serait "facile" de détruire un à un les
objets alloués en affichant ça à l'utilisateur... :
Cependant je pense à une chose délicate, afin d'etre le plus général
possible mon gestionnaire ne doit pas accumuler une liste d'objets sans
ordre... en effet il se peut que certains objets soient dépendant
d'autres, et que leur destructeur requiert qu'un des autres objets soit
encore en vie... il faudrait donc une sorte d'arborescence d'objets à
tuer...
Quelqu'un à -t-il déjà fait quelque chose de similaire ? avez-vous
une/des bonne(s) idée(s) à me proposer ?
En <news:42bd7ccb$0$308$, Richard Delorme va escriure:
Il me semble que les OS rudimentaires, comme MSDOS, ne libérait rien du tout quand le programme quittait.
La version 1 ? En fait si, puisque seul un seul programme existait en tout et pour tout, donc quand il sortait COMMAND.COM remettait tout en jeu, rien de va plus... Idem pour tous les premiers OS, où seul un seul processus pouvait exister à un moment donné (ne serait-ce que pour un souci de taille de mémoire centrale), donc quand il n'existait plus il n'y avait plus de problème de fuite mémoire...
Dès la version 2, tu as un gestionnaire d'allocation mémoire, dont l'un des boulots est de rendre disponible toute la mémoire affectée à un processus lorsque celui-ci terminait son exécution.
Antoine
En <news:42bd7ccb$0$308$7a628cd7@news.club-internet.fr>,
Richard Delorme va escriure:
Il me semble que les OS rudimentaires, comme MSDOS, ne libérait rien
du tout quand le programme quittait.
La version 1 ? En fait si, puisque seul un seul programme existait en tout
et pour tout, donc quand il sortait COMMAND.COM remettait tout en jeu, rien
de va plus...
Idem pour tous les premiers OS, où seul un seul processus pouvait exister à
un moment donné (ne serait-ce que pour un souci de taille de mémoire
centrale), donc quand il n'existait plus il n'y avait plus de problème de
fuite mémoire...
Dès la version 2, tu as un gestionnaire d'allocation mémoire, dont l'un des
boulots est de rendre disponible toute la mémoire affectée à un processus
lorsque celui-ci terminait son exécution.
En <news:42bd7ccb$0$308$, Richard Delorme va escriure:
Il me semble que les OS rudimentaires, comme MSDOS, ne libérait rien du tout quand le programme quittait.
La version 1 ? En fait si, puisque seul un seul programme existait en tout et pour tout, donc quand il sortait COMMAND.COM remettait tout en jeu, rien de va plus... Idem pour tous les premiers OS, où seul un seul processus pouvait exister à un moment donné (ne serait-ce que pour un souci de taille de mémoire centrale), donc quand il n'existait plus il n'y avait plus de problème de fuite mémoire...
Dès la version 2, tu as un gestionnaire d'allocation mémoire, dont l'un des boulots est de rendre disponible toute la mémoire affectée à un processus lorsque celui-ci terminait son exécution.
Antoine
Antoine Leca
En <news:d9mivv$2eg2$, Marc Espie va escriure:
Il existe des implementations de C parfaitement conformes a la norme, ou la memoire non liberee par free n'est pas rendue au systeme en fin d'execution du programme.
Plus precisement, confere 5.1.2.1, Freestanding environment.
Mmmh, c'est un peu poussé... Une implémentation freestanding peut aussi parfaitement fournir malloc() sans fournir free(), ou bien fournir free() sans fournir malloc(), et dans ce dernier cas, free() peut servir à fermer un fichier, ou bien à commander une bière...
Bref, la norme ne prescrit rien en l'occurence.
Omettre les free correspondant aux allocations dynamiques
... n'est pas bien, je suis d'accord.
(Pour que l'on ne se méprenne pas).
Antoine
En <news:d9mivv$2eg2$1@biggoron.nerim.net>, Marc Espie va escriure:
Il existe des implementations de C parfaitement conformes a la norme,
ou la memoire non liberee par free n'est pas rendue au systeme en
fin d'execution du programme.
Plus precisement, confere 5.1.2.1, Freestanding environment.
Mmmh, c'est un peu poussé...
Une implémentation freestanding peut aussi parfaitement fournir malloc()
sans fournir free(), ou bien fournir free() sans fournir malloc(), et dans
ce dernier cas, free() peut servir à fermer un fichier, ou bien à commander
une bière...
Bref, la norme ne prescrit rien en l'occurence.
Omettre les free correspondant aux allocations dynamiques
Il existe des implementations de C parfaitement conformes a la norme, ou la memoire non liberee par free n'est pas rendue au systeme en fin d'execution du programme.
Plus precisement, confere 5.1.2.1, Freestanding environment.
Mmmh, c'est un peu poussé... Une implémentation freestanding peut aussi parfaitement fournir malloc() sans fournir free(), ou bien fournir free() sans fournir malloc(), et dans ce dernier cas, free() peut servir à fermer un fichier, ou bien à commander une bière...
Bref, la norme ne prescrit rien en l'occurence.
Omettre les free correspondant aux allocations dynamiques
... n'est pas bien, je suis d'accord.
(Pour que l'on ne se méprenne pas).
Antoine
espie
In article <d9oept$187$, Antoine Leca wrote:
En <news:d9mivv$2eg2$, Marc Espie va escriure:
Il existe des implementations de C parfaitement conformes a la norme, ou la memoire non liberee par free n'est pas rendue au systeme en fin d'execution du programme.
Plus precisement, confere 5.1.2.1, Freestanding environment.
Mmmh, c'est un peu poussé... Une implémentation freestanding peut aussi parfaitement fournir malloc() sans fournir free(), ou bien fournir free() sans fournir malloc(), et dans ce dernier cas, free() peut servir à fermer un fichier, ou bien à commander une bière...
A la condition que ca soit documente, hein, rappel.
Les fonctions de bibliotheques en extension sont implementation-defined.
Bref, la norme ne prescrit rien en l'occurence.
Farpaitement.
N'empeche qu'on rencontre assez souvent le cas prescrit.
J'ajouterais meme qu'un ami ingenieur m'a raconte recemment l'anecdote suivante au sujet de son entretien d'embauche. On lui a fait passer un test technique, assez classique, genre ecrire un petit programme en C.
Eh bien, le recruteur a lu tres vite son code, a juste note qu'il y avait un free() juste avant la sortie, et lui a dit:
"C'est bien d'y avoir pense. Les autres candidats ont oublie."
Et vlan, il a ete pris.
In article <d9oept$187$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
En <news:d9mivv$2eg2$1@biggoron.nerim.net>, Marc Espie va escriure:
Il existe des implementations de C parfaitement conformes a la norme,
ou la memoire non liberee par free n'est pas rendue au systeme en
fin d'execution du programme.
Plus precisement, confere 5.1.2.1, Freestanding environment.
Mmmh, c'est un peu poussé...
Une implémentation freestanding peut aussi parfaitement fournir malloc()
sans fournir free(), ou bien fournir free() sans fournir malloc(), et dans
ce dernier cas, free() peut servir à fermer un fichier, ou bien à commander
une bière...
A la condition que ca soit documente, hein, rappel.
Les fonctions de bibliotheques en extension sont implementation-defined.
Bref, la norme ne prescrit rien en l'occurence.
Farpaitement.
N'empeche qu'on rencontre assez souvent le cas prescrit.
J'ajouterais meme qu'un ami ingenieur m'a raconte recemment l'anecdote suivante
au sujet de son entretien d'embauche. On lui a fait passer un test technique,
assez classique, genre ecrire un petit programme en C.
Eh bien, le recruteur a lu tres vite son code, a juste note qu'il y avait
un free() juste avant la sortie, et lui a dit:
"C'est bien d'y avoir pense. Les autres candidats ont oublie."
Il existe des implementations de C parfaitement conformes a la norme, ou la memoire non liberee par free n'est pas rendue au systeme en fin d'execution du programme.
Plus precisement, confere 5.1.2.1, Freestanding environment.
Mmmh, c'est un peu poussé... Une implémentation freestanding peut aussi parfaitement fournir malloc() sans fournir free(), ou bien fournir free() sans fournir malloc(), et dans ce dernier cas, free() peut servir à fermer un fichier, ou bien à commander une bière...
A la condition que ca soit documente, hein, rappel.
Les fonctions de bibliotheques en extension sont implementation-defined.
Bref, la norme ne prescrit rien en l'occurence.
Farpaitement.
N'empeche qu'on rencontre assez souvent le cas prescrit.
J'ajouterais meme qu'un ami ingenieur m'a raconte recemment l'anecdote suivante au sujet de son entretien d'embauche. On lui a fait passer un test technique, assez classique, genre ecrire un petit programme en C.
Eh bien, le recruteur a lu tres vite son code, a juste note qu'il y avait un free() juste avant la sortie, et lui a dit:
"C'est bien d'y avoir pense. Les autres candidats ont oublie."
