Bonjour à tous!
J'ai une question toute bete: j'ai des fonctions qui m'affichent à
l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de
pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a
appelée la fonction qui affiche l'erreur.
Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom
fonction appelante" à toutes mes fonctions")?
Merci
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Matthieu Moy
"Zlika" writes:
Bonjour à tous! J'ai une question toute bete: j'ai des fonctions qui m'affichent à l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a appelée la fonction qui affiche l'erreur. Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom fonction appelante" à toutes mes fonctions")?
Moi, j'ai quelque chose comme ça:
#define REPORT_ERROR(msg) cerr << __FILE__ << ":" << __LINE__ << ": bla bla bla" << endl;
Et j'ai configuré mon Emacs pour pouvoir aller à l'endroit de l'erreur en cliquand sur un texte du type "fichier.cpp:42: bla bla bla".
Simple, mais bien pratique !
-- Matthieu
"Zlika" <zlika_eseNikLeSpam@hotmail.com> writes:
Bonjour à tous!
J'ai une question toute bete: j'ai des fonctions qui m'affichent à
l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de
pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a
appelée la fonction qui affiche l'erreur.
Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom
fonction appelante" à toutes mes fonctions")?
Moi, j'ai quelque chose comme ça:
#define REPORT_ERROR(msg)
cerr << __FILE__ << ":" << __LINE__ << ": bla bla bla" << endl;
Et j'ai configuré mon Emacs pour pouvoir aller à l'endroit de l'erreur
en cliquand sur un texte du type "fichier.cpp:42: bla bla bla".
Bonjour à tous! J'ai une question toute bete: j'ai des fonctions qui m'affichent à l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a appelée la fonction qui affiche l'erreur. Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom fonction appelante" à toutes mes fonctions")?
Moi, j'ai quelque chose comme ça:
#define REPORT_ERROR(msg) cerr << __FILE__ << ":" << __LINE__ << ": bla bla bla" << endl;
Et j'ai configuré mon Emacs pour pouvoir aller à l'endroit de l'erreur en cliquand sur un texte du type "fichier.cpp:42: bla bla bla".
Simple, mais bien pratique !
-- Matthieu
Zlika
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
"Matthieu Moy" a écrit dans le message de news:
"Zlika" writes:
Bonjour à tous! J'ai une question toute bete: j'ai des fonctions qui m'affichent à l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a appelée la fonction qui affiche l'erreur. Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom fonction appelante" à toutes mes fonctions")?
Moi, j'ai quelque chose comme ça:
#define REPORT_ERROR(msg) cerr << __FILE__ << ":" << __LINE__ << ": bla bla bla" << endl;
Et j'ai configuré mon Emacs pour pouvoir aller à l'endroit de l'erreur en cliquand sur un texte du type "fichier.cpp:42: bla bla bla".
Simple, mais bien pratique !
-- Matthieu
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite
l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette
fonction. Tu vois ce que je veux dire?
"Matthieu Moy" <MatthieuNOSPAM.Moy@imag.fr.invalid> a écrit dans le message
de news: vpqd5q06wot.fsf@ecrins.imag.fr...
"Zlika" <zlika_eseNikLeSpam@hotmail.com> writes:
Bonjour à tous!
J'ai une question toute bete: j'ai des fonctions qui m'affichent à
l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de
pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a
appelée la fonction qui affiche l'erreur.
Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom
fonction appelante" à toutes mes fonctions")?
Moi, j'ai quelque chose comme ça:
#define REPORT_ERROR(msg)
cerr << __FILE__ << ":" << __LINE__ << ": bla bla bla" << endl;
Et j'ai configuré mon Emacs pour pouvoir aller à l'endroit de l'erreur
en cliquand sur un texte du type "fichier.cpp:42: bla bla bla".
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
"Matthieu Moy" a écrit dans le message de news:
"Zlika" writes:
Bonjour à tous! J'ai une question toute bete: j'ai des fonctions qui m'affichent à l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a appelée la fonction qui affiche l'erreur. Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom fonction appelante" à toutes mes fonctions")?
Moi, j'ai quelque chose comme ça:
#define REPORT_ERROR(msg) cerr << __FILE__ << ":" << __LINE__ << ": bla bla bla" << endl;
Et j'ai configuré mon Emacs pour pouvoir aller à l'endroit de l'erreur en cliquand sur un texte du type "fichier.cpp:42: bla bla bla".
Simple, mais bien pratique !
-- Matthieu
Matthieu Moy
"Zlika" writes:
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
Merci de lire ça d'abord :
http://www.giromini.org/usenet-fr/repondre.html
Sinon, pour ton problème, la solution « simple » (mais pas belle) est de remplacer la fonction par une macro, et __FILE__ et __LINE__ seront expansés à l'endroit de l'appel de la macro.
La solution classique, c'est de laisser comme ça et d'utiliser un débogueur pour avoir plus d'info (commandes "up" et "where" dans gdb).
Y'a sans doute moyen de récupérer la pile d'execution, mais je ne sais pas faire en C++, et ça a de forte chances d'être un truc non portable.
-- Matthieu
"Zlika" <zlika_eseNikLeSpam@hotmail.com> writes:
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite
l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette
fonction. Tu vois ce que je veux dire?
Merci de lire ça d'abord :
http://www.giromini.org/usenet-fr/repondre.html
Sinon, pour ton problème, la solution « simple » (mais pas belle) est
de remplacer la fonction par une macro, et __FILE__ et __LINE__ seront
expansés à l'endroit de l'appel de la macro.
La solution classique, c'est de laisser comme ça et d'utiliser un
débogueur pour avoir plus d'info (commandes "up" et "where" dans gdb).
Y'a sans doute moyen de récupérer la pile d'execution, mais je ne sais
pas faire en C++, et ça a de forte chances d'être un truc non
portable.
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
Merci de lire ça d'abord :
http://www.giromini.org/usenet-fr/repondre.html
Sinon, pour ton problème, la solution « simple » (mais pas belle) est de remplacer la fonction par une macro, et __FILE__ et __LINE__ seront expansés à l'endroit de l'appel de la macro.
La solution classique, c'est de laisser comme ça et d'utiliser un débogueur pour avoir plus d'info (commandes "up" et "where" dans gdb).
Y'a sans doute moyen de récupérer la pile d'execution, mais je ne sais pas faire en C++, et ça a de forte chances d'être un truc non portable.
-- Matthieu
Cyrille
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
Le langage C++ ne fournit pas lui-même de moyen pour accéder au nom des fonctions ou au stack des appels de fonctions. On peut utiliser d'une part des débuggers, soit des fonctions non portables fournies par le système. Sous Windows, renseignez-vous sur la fonction StackWalk64, je pense que c'est ce qui vous intéresse, sans en être sûr.
-- "I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite
l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette
fonction. Tu vois ce que je veux dire?
Le langage C++ ne fournit pas lui-même de moyen pour accéder au nom des
fonctions ou au stack des appels de fonctions.
On peut utiliser d'une part des débuggers, soit des fonctions non
portables fournies par le système. Sous Windows, renseignez-vous sur la
fonction StackWalk64, je pense que c'est ce qui vous intéresse, sans en
être sûr.
--
"I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
Le langage C++ ne fournit pas lui-même de moyen pour accéder au nom des fonctions ou au stack des appels de fonctions. On peut utiliser d'une part des débuggers, soit des fonctions non portables fournies par le système. Sous Windows, renseignez-vous sur la fonction StackWalk64, je pense que c'est ce qui vous intéresse, sans en être sûr.
-- "I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
kanze
Matthieu Moy wrote:
"Zlika" writes:
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
Sinon, pour ton problème, la solution « simple » (mais pas belle) est de remplacer la fonction par une macro, et __FILE__ et __LINE__ seront expansés à l'endroit de l'appel de la macro.
La solution classique, c'est de laisser comme ça et d'utiliser un débogueur pour avoir plus d'info (commandes "up" et "where" dans gdb).
C'est une possibilité, mais ça suppose que le client t'envoie un core dump. Ce qui suppose que l'erreur était assez grave pour en générer un.
Plus généralement, on protocole à peu près tout ce qui peut être intéressant, y compris l'entrée dans et la sortie de chaque fonction non-triviale. (L'idiome RAII sert bien ici.) On récupère les logs, et on voit d'où on est venu.
Y'a sans doute moyen de récupérer la pile d'execution, mais je ne sais pas faire en C++, et ça a de forte chances d'être un truc non portable.
C'est tout à fait non portable. En revanche, c'est typiquement assez simple si on sait le faire -- j'ai du code pour le faire sur Sparc et sur Intel IA-32. Si on se sert de g++, il y a aussi des fonctions __builtin_return_address et __builtin_frame_address qui pourrait être utiles.
Dans tous les cas, évidemment, on se rétrouve avec une valeur binaire (qu'on peut afficher en hex, octal, ou même décimal), et non un nom symbolique. Si on ne s'en sert pas souvent, il se peut que ça suffit, mais il existe aussi d'autres outils : dans les binutils de GNU, par exemple, il y a une commande addr2line, qui à partir d'un fichier d'exécution et une adresse hex, permet à rétrouver le nom du fichier source, le numéro de ligne, et éventuellement le nom de la fonction. La doc ne le dit pas, mais je suppose qu'il y a des restrictions sur l'exécutable : qu'il contient les infos de débogguage, par exemple, et peut-être des limitations sur le compilateur qui l'a généré ou le format. Sinon, il est prèsque toujours possible d'obtenir un map du programme, soit du linker, soit avec un programme séparé -- on trie le mappe en ordre des adresses, et on y va :-).
-- 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
Matthieu Moy wrote:
"Zlika" <zlika_eseNikLeSpam@hotmail.com> writes:
Merci mais ça ça te donne le nom/ligne du fichier où c'est
produite l'erreur. Je voudrais plutot une indication de la
fonction qui appelle cette fonction. Tu vois ce que je veux
dire?
Sinon, pour ton problème, la solution « simple » (mais pas
belle) est de remplacer la fonction par une macro, et __FILE__
et __LINE__ seront expansés à l'endroit de l'appel de la
macro.
La solution classique, c'est de laisser comme ça et d'utiliser
un débogueur pour avoir plus d'info (commandes "up" et "where"
dans gdb).
C'est une possibilité, mais ça suppose que le client t'envoie
un core dump. Ce qui suppose que l'erreur était assez grave pour
en générer un.
Plus généralement, on protocole à peu près tout ce qui peut être
intéressant, y compris l'entrée dans et la sortie de chaque
fonction non-triviale. (L'idiome RAII sert bien ici.) On
récupère les logs, et on voit d'où on est venu.
Y'a sans doute moyen de récupérer la pile d'execution, mais je
ne sais pas faire en C++, et ça a de forte chances d'être un
truc non portable.
C'est tout à fait non portable. En revanche, c'est typiquement
assez simple si on sait le faire -- j'ai du code pour le faire
sur Sparc et sur Intel IA-32. Si on se sert de g++, il y a aussi
des fonctions __builtin_return_address et
__builtin_frame_address qui pourrait être utiles.
Dans tous les cas, évidemment, on se rétrouve avec une valeur
binaire (qu'on peut afficher en hex, octal, ou même décimal), et
non un nom symbolique. Si on ne s'en sert pas souvent, il se
peut que ça suffit, mais il existe aussi d'autres outils : dans
les binutils de GNU, par exemple, il y a une commande addr2line,
qui à partir d'un fichier d'exécution et une adresse hex, permet
à rétrouver le nom du fichier source, le numéro de ligne, et
éventuellement le nom de la fonction. La doc ne le dit pas, mais
je suppose qu'il y a des restrictions sur l'exécutable : qu'il
contient les infos de débogguage, par exemple, et peut-être des
limitations sur le compilateur qui l'a généré ou le format.
Sinon, il est prèsque toujours possible d'obtenir un map du
programme, soit du linker, soit avec un programme séparé -- on
trie le mappe en ordre des adresses, et on y va :-).
--
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
Merci mais ça ça te donne le nom/ligne du fichier où c'est produite l'erreur. Je voudrais plutot une indication de la fonction qui appelle cette fonction. Tu vois ce que je veux dire?
Sinon, pour ton problème, la solution « simple » (mais pas belle) est de remplacer la fonction par une macro, et __FILE__ et __LINE__ seront expansés à l'endroit de l'appel de la macro.
La solution classique, c'est de laisser comme ça et d'utiliser un débogueur pour avoir plus d'info (commandes "up" et "where" dans gdb).
C'est une possibilité, mais ça suppose que le client t'envoie un core dump. Ce qui suppose que l'erreur était assez grave pour en générer un.
Plus généralement, on protocole à peu près tout ce qui peut être intéressant, y compris l'entrée dans et la sortie de chaque fonction non-triviale. (L'idiome RAII sert bien ici.) On récupère les logs, et on voit d'où on est venu.
Y'a sans doute moyen de récupérer la pile d'execution, mais je ne sais pas faire en C++, et ça a de forte chances d'être un truc non portable.
C'est tout à fait non portable. En revanche, c'est typiquement assez simple si on sait le faire -- j'ai du code pour le faire sur Sparc et sur Intel IA-32. Si on se sert de g++, il y a aussi des fonctions __builtin_return_address et __builtin_frame_address qui pourrait être utiles.
Dans tous les cas, évidemment, on se rétrouve avec une valeur binaire (qu'on peut afficher en hex, octal, ou même décimal), et non un nom symbolique. Si on ne s'en sert pas souvent, il se peut que ça suffit, mais il existe aussi d'autres outils : dans les binutils de GNU, par exemple, il y a une commande addr2line, qui à partir d'un fichier d'exécution et une adresse hex, permet à rétrouver le nom du fichier source, le numéro de ligne, et éventuellement le nom de la fonction. La doc ne le dit pas, mais je suppose qu'il y a des restrictions sur l'exécutable : qu'il contient les infos de débogguage, par exemple, et peut-être des limitations sur le compilateur qui l'a généré ou le format. Sinon, il est prèsque toujours possible d'obtenir un map du programme, soit du linker, soit avec un programme séparé -- on trie le mappe en ordre des adresses, et on y va :-).
-- 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
D!m
Zlika wrote:
Bonjour à tous! J'ai une question toute bete: j'ai des fonctions qui m'affichent à l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a appelée la fonction qui affiche l'erreur. Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom fonction appelante" à toutes mes fonctions")? Merci
Zlika
Il y a rien dans la norme. Après ca depend du comilateur, par exemple Gcc le fournit avec __PRETTY_FUNCTION__
-- haltef4
Zlika wrote:
Bonjour à tous!
J'ai une question toute bete: j'ai des fonctions qui m'affichent à
l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de
pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a
appelée la fonction qui affiche l'erreur.
Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom
fonction appelante" à toutes mes fonctions")?
Merci
Zlika
Il y a rien dans la norme. Après ca depend du comilateur, par exemple
Gcc le fournit avec __PRETTY_FUNCTION__
Bonjour à tous! J'ai une question toute bete: j'ai des fonctions qui m'affichent à l'occasion des messages d'erreurs. Ce qui m'aiderait énormenent, c'est de pouvoir afficher dans ces messages d'erreurs le nom de la fonction qui a appelée la fonction qui affiche l'erreur. Est-il possible de faire ça simplement (ie. sans rajouter une entrée "nom fonction appelante" à toutes mes fonctions")? Merci
Zlika
Il y a rien dans la norme. Après ca depend du comilateur, par exemple Gcc le fournit avec __PRETTY_FUNCTION__
