J'ai r=E9cement =E9t=E9 confront=E9 =E0 un probl=E8me que je n'ai su r=E9so=
udre : dans le main(), suite =E0 un exit(1), mon programme s'arretait en "s=
egmentation fault". Une fois le exit(1) remplac=E9 par un return 1, plus de=
probl=E8mes. (A titre d'informations, je n'ai eu ce probl=E8me que sous DE=
C OSF1. Sous HP-UX et sous GNU/Linux, aucun probl=E8mes)
J'aurais aim=E9 savoir si la norme pr=E9voyait un comportement diff=E9rent =
entre un appel =E0 exit(1) et =E0 return 1 dans le main. Je pensais que les=
deux fonctions appelaient les destructeurs des objets de main() puis les d=
estructeurs des objets globaux, mais le comportement ci-dessus semble montr=
er que non.
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++. Les exceptions peuvent être une alternative.
-- Aurélien Regat-Barrel
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Les exceptions peuvent être une alternative.
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++. Les exceptions peuvent être une alternative.
-- Aurélien Regat-Barrel
kanze
Snoopy wrote:
J'ai récement été confronté à un problème que je n'ai su résoudre : dans le main(), suite à un exit(1), mon programme s'arretait en "segmentation fault". Une fois le exit(1) remplacé par un return 1, plus de problèmes. (A titre d'informations, je n'ai eu ce problème que sous DEC OSF1. Sous HP-UX et sous GNU/Linux, aucun problèmes)
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
Quand tu appelles exit(), les destructeurs des variables locales ne sont pas appelés. Selon l'implémentation, si une de ces variables s'inscrit dans un objet statique, et que cet objet essaie d'y accéder dans son destructeur, il peut y avoir un problème.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Snoopy wrote:
J'ai récement été confronté à un problème que je n'ai su
résoudre : dans le main(), suite à un exit(1), mon programme
s'arretait en "segmentation fault". Une fois le exit(1)
remplacé par un return 1, plus de problèmes. (A titre
d'informations, je n'ai eu ce problème que sous DEC OSF1. Sous
HP-UX et sous GNU/Linux, aucun problèmes)
J'aurais aimé savoir si la norme prévoyait un comportement
différent entre un appel à exit(1) et à return 1 dans le main.
Je pensais que les deux fonctions appelaient les destructeurs
des objets de main() puis les destructeurs des objets globaux,
mais le comportement ci-dessus semble montrer que non.
Quand tu appelles exit(), les destructeurs des variables locales
ne sont pas appelés. Selon l'implémentation, si une de ces
variables s'inscrit dans un objet statique, et que cet objet
essaie d'y accéder dans son destructeur, il peut y avoir un
problème.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'ai récement été confronté à un problème que je n'ai su résoudre : dans le main(), suite à un exit(1), mon programme s'arretait en "segmentation fault". Une fois le exit(1) remplacé par un return 1, plus de problèmes. (A titre d'informations, je n'ai eu ce problème que sous DEC OSF1. Sous HP-UX et sous GNU/Linux, aucun problèmes)
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
Quand tu appelles exit(), les destructeurs des variables locales ne sont pas appelés. Selon l'implémentation, si une de ces variables s'inscrit dans un objet statique, et que cet objet essaie d'y accéder dans son destructeur, il peut y avoir un problème.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues
Snoopy wrote:
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
La norme dit « Calling the function void exit(int); declared in <cstdlib> (18.3) terminates the program without leaving the current block and hence without destroying any objects with automatic storage duration (12.4). If exit is called to end a program during the destruction of an object with static storage duration, the program has undefined behavior. »
-- Arnaud
Snoopy wrote:
J'aurais aimé savoir si la norme prévoyait un comportement différent
entre un appel à exit(1) et à return 1 dans le main. Je pensais que
les deux fonctions appelaient les destructeurs des objets de main()
puis les destructeurs des objets globaux, mais le comportement
ci-dessus semble montrer que non.
La norme dit
«
Calling the function
void exit(int);
declared in <cstdlib> (18.3) terminates the program without leaving the
current block and hence without destroying any objects with automatic
storage duration (12.4). If exit is called to end a program during the
destruction of an object with static storage duration, the program has
undefined behavior.
»
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
La norme dit « Calling the function void exit(int); declared in <cstdlib> (18.3) terminates the program without leaving the current block and hence without destroying any objects with automatic storage duration (12.4). If exit is called to end a program during the destruction of an object with static storage duration, the program has undefined behavior. »
-- Arnaud
kanze
Aurelien Regat-Barrel wrote:
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
En fin de compte, tout dépend de la séverité de l'erreur. Pour des erreurs normales, on affiche sur std::cerr, et on s'arrange pour que la valeur renvoyée par main soit quelque chose qui signifie erreur (EXIT_FAILURE pour un maximum de portabilité). Pour des erreurs fatales, on appelle exit(), et pour les erreurs internes, qui ne peuvent jamais se produire (les échecs d'assertion, etc.), on appelle abort().
Les exceptions peuvent être une alternative.
J'y ai effectivement considérer la possibilité d'utiliser throw int à la place d'exit(). Ça impose que le main l'attrappe et fait le return. (sinon, c'est un abort().) AMHA, ce serait une bonne convention, mais je ne l'ai jamais vu appliquée, ni même pas conseillée.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aurelien Regat-Barrel wrote:
J'aurais aimé savoir si la norme prévoyait un comportement
différent entre un appel à exit(1) et à return 1 dans le
main. Je pensais que les deux fonctions appelaient les
destructeurs des objets de main() puis les destructeurs des
objets globaux, mais le comportement ci-dessus semble
montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser
exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux
appeler abort() aussi.
En fin de compte, tout dépend de la séverité de l'erreur. Pour
des erreurs normales, on affiche sur std::cerr, et on s'arrange
pour que la valeur renvoyée par main soit quelque chose qui
signifie erreur (EXIT_FAILURE pour un maximum de portabilité).
Pour des erreurs fatales, on appelle exit(), et pour les erreurs
internes, qui ne peuvent jamais se produire (les échecs
d'assertion, etc.), on appelle abort().
Les exceptions peuvent être une alternative.
J'y ai effectivement considérer la possibilité d'utiliser throw
int à la place d'exit(). Ça impose que le main l'attrappe et
fait le return. (sinon, c'est un abort().) AMHA, ce serait une
bonne convention, mais je ne l'ai jamais vu appliquée, ni même
pas conseillée.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
En fin de compte, tout dépend de la séverité de l'erreur. Pour des erreurs normales, on affiche sur std::cerr, et on s'arrange pour que la valeur renvoyée par main soit quelque chose qui signifie erreur (EXIT_FAILURE pour un maximum de portabilité). Pour des erreurs fatales, on appelle exit(), et pour les erreurs internes, qui ne peuvent jamais se produire (les échecs d'assertion, etc.), on appelle abort().
Les exceptions peuvent être une alternative.
J'y ai effectivement considérer la possibilité d'utiliser throw int à la place d'exit(). Ça impose que le main l'attrappe et fait le return. (sinon, c'est un abort().) AMHA, ce serait une bonne convention, mais je ne l'ai jamais vu appliquée, ni même pas conseillée.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet
"kanze" writes:
Aurelien Regat-Barrel wrote:
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up (ce qui est enregistre avec atexit, les fichiers) mais pas tout. J'ai du mal a voir une situation ou c'est utile.
J'y ai effectivement considérer la possibilité d'utiliser throw int à la place d'exit(). Ça impose que le main l'attrappe et fait le return. (sinon, c'est un abort().) AMHA, ce serait une bonne convention, mais je ne l'ai jamais vu appliquée, ni même pas conseillée.
J'utilise ca dans mes programmes perso depuis longtemps. Au boulot ca fait longtemps que je n'ai pas eu a ecrire le main (je ne suis pas sur de l'avoir deja fait pour autre chose que des tests d'ailleurs).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"kanze" <kanze@gabi-soft.fr> writes:
Aurelien Regat-Barrel wrote:
J'aurais aimé savoir si la norme prévoyait un comportement
différent entre un appel à exit(1) et à return 1 dans le
main. Je pensais que les deux fonctions appelaient les
destructeurs des objets de main() puis les destructeurs des
objets globaux, mais le comportement ci-dessus semble
montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser
exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux
appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up
(ce qui est enregistre avec atexit, les fichiers) mais pas tout.
J'ai du mal a voir une situation ou c'est utile.
J'y ai effectivement considérer la possibilité d'utiliser throw
int à la place d'exit(). Ça impose que le main l'attrappe et
fait le return. (sinon, c'est un abort().) AMHA, ce serait une
bonne convention, mais je ne l'ai jamais vu appliquée, ni même
pas conseillée.
J'utilise ca dans mes programmes perso depuis longtemps. Au boulot ca
fait longtemps que je n'ai pas eu a ecrire le main (je ne suis pas sur
de l'avoir deja fait pour autre chose que des tests d'ailleurs).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up (ce qui est enregistre avec atexit, les fichiers) mais pas tout. J'ai du mal a voir une situation ou c'est utile.
J'y ai effectivement considérer la possibilité d'utiliser throw int à la place d'exit(). Ça impose que le main l'attrappe et fait le return. (sinon, c'est un abort().) AMHA, ce serait une bonne convention, mais je ne l'ai jamais vu appliquée, ni même pas conseillée.
J'utilise ca dans mes programmes perso depuis longtemps. Au boulot ca fait longtemps que je n'ai pas eu a ecrire le main (je ne suis pas sur de l'avoir deja fait pour autre chose que des tests d'ailleurs).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aurelien Regat-Barrel
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up (ce qui est enregistre avec atexit, les fichiers) mais pas tout. J'ai du mal a voir une situation ou c'est utile.
Autant pour moi, je croyais exit() plus brutal. Après consultation des sources de la CRT de VC++ 7.1, exit() tue directement le process qu'en cas d'appel récursif.
-- Aurélien Regat-Barrel
exit() tue ton programme. Pan t'es mort. Faut pas utiliser
exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux
appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up
(ce qui est enregistre avec atexit, les fichiers) mais pas tout.
J'ai du mal a voir une situation ou c'est utile.
Autant pour moi, je croyais exit() plus brutal. Après consultation des
sources de la CRT de VC++ 7.1, exit() tue directement le process qu'en
cas d'appel récursif.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up (ce qui est enregistre avec atexit, les fichiers) mais pas tout. J'ai du mal a voir une situation ou c'est utile.
Autant pour moi, je croyais exit() plus brutal. Après consultation des sources de la CRT de VC++ 7.1, exit() tue directement le process qu'en cas d'appel récursif.
-- Aurélien Regat-Barrel
kanze
Jean-Marc Bourguet wrote:
"kanze" writes:
Aurelien Regat-Barrel wrote:
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up (ce qui est enregistre avec atexit, les fichiers) mais pas tout. J'ai du mal a voir une situation ou c'est utile.
Ça dépend. Je l'ai prévu dans mon ProgramStatus : sévérité fatal mène à l'exit, sévérité internal à abort. En fait, je l'utilise bien, mais prèsque toujours dans le cas d'une erreur qui empêche de démarrer le traitement (donc, avant l'allocation des ressources), genre erreur dans le fichier de configuration, où dans les options de la ligne de commande.
J'avoue que je vois ça beaucoup d'une perspective Unix. Où la différence n'est pas seulement la quantité de nettoyage, mais aussi la présence ou l'absence d'un core dump. Si les conditions de démarrage ne sont pas rempli, ce n'est pas la peine de générer un core, même si ce que je veux, c'est bien un arrêt brutal. (Aussi, évidemment, la plupart des ressources sont libérées automatiquement par le système en fin de processus.)
Logiquement, donc, pour moi, exit(), c'est un abort() sans le core dump.
J'y ai effectivement considérer la possibilité d'utiliser throw int à la place d'exit(). Ça impose que le main l'attrappe et fait le return. (sinon, c'est un abort().) AMHA, ce serait une bonne convention, mais je ne l'ai jamais vu appliquée, ni même pas conseillée.
J'utilise ca dans mes programmes perso depuis longtemps. Au boulot ca fait longtemps que je n'ai pas eu a ecrire le main (je ne suis pas sur de l'avoir deja fait pour autre chose que des tests d'ailleurs).
Pour l'utiliser, il faut bien que ce soit une politique établie. Je m'en suis expérimenté un peu, et l'idée me plaît. Mais dans la mesure où je ne veux pas que ProgramStatus impose une technique donnée, et qu'elle soit utilisable à peu près partout, c'est un peu difficile.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
"kanze" <kanze@gabi-soft.fr> writes:
Aurelien Regat-Barrel wrote:
J'aurais aimé savoir si la norme prévoyait un
comportement différent entre un appel à exit(1) et à
return 1 dans le main. Je pensais que les deux fonctions
appelaient les destructeurs des objets de main() puis
les destructeurs des objets globaux, mais le
comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser
exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux
appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up
(ce qui est enregistre avec atexit, les fichiers) mais pas
tout. J'ai du mal a voir une situation ou c'est utile.
Ça dépend. Je l'ai prévu dans mon ProgramStatus : sévérité fatal
mène à l'exit, sévérité internal à abort. En fait, je l'utilise
bien, mais prèsque toujours dans le cas d'une erreur qui empêche
de démarrer le traitement (donc, avant l'allocation des
ressources), genre erreur dans le fichier de configuration, où
dans les options de la ligne de commande.
J'avoue que je vois ça beaucoup d'une perspective Unix. Où la
différence n'est pas seulement la quantité de nettoyage, mais
aussi la présence ou l'absence d'un core dump. Si les conditions
de démarrage ne sont pas rempli, ce n'est pas la peine de
générer un core, même si ce que je veux, c'est bien un arrêt
brutal. (Aussi, évidemment, la plupart des ressources sont
libérées automatiquement par le système en fin de processus.)
Logiquement, donc, pour moi, exit(), c'est un abort() sans le
core dump.
J'y ai effectivement considérer la possibilité d'utiliser
throw int à la place d'exit(). Ça impose que le main
l'attrappe et fait le return. (sinon, c'est un abort().)
AMHA, ce serait une bonne convention, mais je ne l'ai jamais
vu appliquée, ni même pas conseillée.
J'utilise ca dans mes programmes perso depuis longtemps. Au
boulot ca fait longtemps que je n'ai pas eu a ecrire le main
(je ne suis pas sur de l'avoir deja fait pour autre chose que
des tests d'ailleurs).
Pour l'utiliser, il faut bien que ce soit une politique établie.
Je m'en suis expérimenté un peu, et l'idée me plaît. Mais dans
la mesure où je ne veux pas que ProgramStatus impose une
technique donnée, et qu'elle soit utilisable à peu près partout,
c'est un peu difficile.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'aurais aimé savoir si la norme prévoyait un comportement différent entre un appel à exit(1) et à return 1 dans le main. Je pensais que les deux fonctions appelaient les destructeurs des objets de main() puis les destructeurs des objets globaux, mais le comportement ci-dessus semble montrer que non.
exit() tue ton programme. Pan t'es mort. Faut pas utiliser exit en C++.
Ça dépend. C'est comme abort() -- il y a des cas où tu veux appeler abort() aussi.
abort je comprends. exit() non: on fait une partie du clean-up (ce qui est enregistre avec atexit, les fichiers) mais pas tout. J'ai du mal a voir une situation ou c'est utile.
Ça dépend. Je l'ai prévu dans mon ProgramStatus : sévérité fatal mène à l'exit, sévérité internal à abort. En fait, je l'utilise bien, mais prèsque toujours dans le cas d'une erreur qui empêche de démarrer le traitement (donc, avant l'allocation des ressources), genre erreur dans le fichier de configuration, où dans les options de la ligne de commande.
J'avoue que je vois ça beaucoup d'une perspective Unix. Où la différence n'est pas seulement la quantité de nettoyage, mais aussi la présence ou l'absence d'un core dump. Si les conditions de démarrage ne sont pas rempli, ce n'est pas la peine de générer un core, même si ce que je veux, c'est bien un arrêt brutal. (Aussi, évidemment, la plupart des ressources sont libérées automatiquement par le système en fin de processus.)
Logiquement, donc, pour moi, exit(), c'est un abort() sans le core dump.
J'y ai effectivement considérer la possibilité d'utiliser throw int à la place d'exit(). Ça impose que le main l'attrappe et fait le return. (sinon, c'est un abort().) AMHA, ce serait une bonne convention, mais je ne l'ai jamais vu appliquée, ni même pas conseillée.
J'utilise ca dans mes programmes perso depuis longtemps. Au boulot ca fait longtemps que je n'ai pas eu a ecrire le main (je ne suis pas sur de l'avoir deja fait pour autre chose que des tests d'ailleurs).
Pour l'utiliser, il faut bien que ce soit une politique établie. Je m'en suis expérimenté un peu, et l'idée me plaît. Mais dans la mesure où je ne veux pas que ProgramStatus impose une technique donnée, et qu'elle soit utilisable à peu près partout, c'est un peu difficile.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 15 Sep 2005 23:37:35 -0700, "kanze" :
aussi la présence ou l'absence d'un core dump.
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un core dump ?
On 15 Sep 2005 23:37:35 -0700, "kanze" <kanze@gabi-soft.fr>:
aussi la présence ou l'absence d'un core dump.
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un
core dump ?
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un core dump ?
Richard Delorme
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un core dump ?
A deux choses : - A déboguer une application après coup. Normalement pour déboguer, il faut lancer l'application depuis le débogueur, et attendre l'interruption inopinée du programme pour savoir où ça foire. Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application. - A remplir le disque dur, à la plus grande joie des vendeurs.
-- Richard
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un
core dump ?
A deux choses :
- A déboguer une application après coup. Normalement pour déboguer, il
faut lancer l'application depuis le débogueur, et attendre
l'interruption inopinée du programme pour savoir où ça foire. Avec le
core-dump, qui est une image mémoire de l'application, le débogueur peut
retrouver l'erreur sans avoir besoin de relancer l'application.
- A remplir le disque dur, à la plus grande joie des vendeurs.
Question de béotien (ou de non-unixien) : ça sert à quelque chose, un core dump ?
A deux choses : - A déboguer une application après coup. Normalement pour déboguer, il faut lancer l'application depuis le débogueur, et attendre l'interruption inopinée du programme pour savoir où ça foire. Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application. - A remplir le disque dur, à la plus grande joie des vendeurs.
-- Richard
Fabien LE LEZ
On Fri, 16 Sep 2005 20:16:45 +0200, Richard Delorme :
Avec le core-dump, qui est une image mémoire de l'application, le débogueur peut retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les infos utiles, c'est ça ?
- A remplir le disque dur, à la plus grande joie des vendeurs.
'sont pas effacées automatiquement, ces bestioles ?
On Fri, 16 Sep 2005 20:16:45 +0200, Richard Delorme
<abulmo@nospam.fr>:
Avec le
core-dump, qui est une image mémoire de l'application, le débogueur peut
retrouver l'erreur sans avoir besoin de relancer l'application.
On lance gdb avec ce fichier comme paramètre et il te donne toutes les
infos utiles, c'est ça ?
- A remplir le disque dur, à la plus grande joie des vendeurs.
'sont pas effacées automatiquement, ces bestioles ?
