Bonjour,
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage), j'ai
utilisé une macro que j'avais trouvé sur la toile :
#ifndef __func__
#ifdef __FUNCTION__
#define __func__ __FUNCTION__
#else
#ifdef __FUNC__
#define __func__ __FUNC__
#else
#define __func__ "<unknow>"
#endif
#endif
#endif
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction (il semble accessible sous la forme d'une
variable local de type ''static const char __func__[];'').
Bonjour,
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage), j'ai
utilisé une macro que j'avais trouvé sur la toile :
#ifndef __func__
#ifdef __FUNCTION__
#define __func__ __FUNCTION__
#else
#ifdef __FUNC__
#define __func__ __FUNC__
#else
#define __func__ "<unknow>"
#endif
#endif
#endif
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction (il semble accessible sous la forme d'une
variable local de type ''static const char __func__[];'').
Bonjour,
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage), j'ai
utilisé une macro que j'avais trouvé sur la toile :
#ifndef __func__
#ifdef __FUNCTION__
#define __func__ __FUNCTION__
#else
#ifdef __FUNC__
#define __func__ __FUNC__
#else
#define __func__ "<unknow>"
#endif
#endif
#endif
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction (il semble accessible sous la forme d'une
variable local de type ''static const char __func__[];'').
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Du coup, je recherche une solution pour remplacer la macro initiale.
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Du coup, je recherche une solution pour remplacer la macro initiale.
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Du coup, je recherche une solution pour remplacer la macro initiale.
smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste > où la solution actuelle plante-t-elle et comment ?)
Antoine
smu wrote:
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste > où la solution actuelle plante-t-elle et comment ?)
Antoine
smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste > où la solution actuelle plante-t-elle et comment ?)
Antoine
smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui ne
sont pas tous conforme au standard C99.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste >> où la solution actuelle plante-t-elle et comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
smu wrote:
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui ne
sont pas tous conforme au standard C99.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste >> où la solution actuelle plante-t-elle et comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui ne
sont pas tous conforme au standard C99.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste >> où la solution actuelle plante-t-elle et comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
In article <et67et$ot7$, smu wrote:smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui ne
sont pas tous conforme au standard C99.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Oui, mais tout ceci etait pre-standard 99.Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste >>> où la solution actuelle plante-t-elle et comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution est simple: si tu es C99, tu n'as pas a t'ennuyer avec tout ca,
et tu testes juste la valeur de __STDC_VERSION__...
Sinon, eh bien tu retombes sur le code que tu as deja... j'ai du mal a voir
ou est le probleme.
In article <et67et$ot7$1@s1.news.oleane.net>, smu <pas@d.adresse> wrote:
smu wrote:
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui ne
sont pas tous conforme au standard C99.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Oui, mais tout ceci etait pre-standard 99.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste >>> où la solution actuelle plante-t-elle et comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution est simple: si tu es C99, tu n'as pas a t'ennuyer avec tout ca,
et tu testes juste la valeur de __STDC_VERSION__...
Sinon, eh bien tu retombes sur le code que tu as deja... j'ai du mal a voir
ou est le probleme.
In article <et67et$ot7$, smu wrote:smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__) sur de
multiples compilateurs, tu devrais te proteger avec __STDC_VERSION__... mais
bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui ne
sont pas tous conforme au standard C99.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est accessible qu'à
l'intérieur de la définition ; quand on y réfléchit, on a du mal à voir
comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Oui, mais tout ceci etait pre-standard 99.Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler (imprimer
quoi, dans quel contexte, dans quelles conditions le problème se manifeste >>> où la solution actuelle plante-t-elle et comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution est simple: si tu es C99, tu n'as pas a t'ennuyer avec tout ca,
et tu testes juste la valeur de __STDC_VERSION__...
Sinon, eh bien tu retombes sur le code que tu as deja... j'ai du mal a voir
ou est le probleme.
smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
smu wrote:
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution est simple: si tu es C99, tu n'as pas a t'ennuyer avec
tout ca, et tu testes juste la valeur de __STDC_VERSION__...
Sinon, eh bien tu retombes sur le code que tu as deja... j'ai du mal
a voir ou est le probleme.
Le problème est que je ne veux pas gérer du code pour les compilos C99
et du code pour les compilos non-C99.
De plus, ce n'est pas moins qui décide du compilo que les clients vont
utiliser.
C'est pour cela que je cherche une solution passe-partout.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution est simple: si tu es C99, tu n'as pas a t'ennuyer avec
tout ca, et tu testes juste la valeur de __STDC_VERSION__...
Sinon, eh bien tu retombes sur le code que tu as deja... j'ai du mal
a voir ou est le probleme.
Le problème est que je ne veux pas gérer du code pour les compilos C99
et du code pour les compilos non-C99.
De plus, ce n'est pas moins qui décide du compilo que les clients vont
utiliser.
C'est pour cela que je cherche une solution passe-partout.
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
La solution est simple: si tu es C99, tu n'as pas a t'ennuyer avec
tout ca, et tu testes juste la valeur de __STDC_VERSION__...
Sinon, eh bien tu retombes sur le code que tu as deja... j'ai du mal
a voir ou est le probleme.
Le problème est que je ne veux pas gérer du code pour les compilos C99
et du code pour les compilos non-C99.
De plus, ce n'est pas moins qui décide du compilo que les clients vont
utiliser.
C'est pour cela que je cherche une solution passe-partout.
smu wrote:smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
J'ai du mal à te suivre.
Tu définis conditionnellement __func__ (à __FUNCTION__ OU __FUNC__), la
condition étant que __STDC_VERSION__ soit inférieur à 199901L; si
__STDC_VERSION__ est supérieur à 199901L, *et* que __func__ ne se comporte
pas comme il faut, tu reportes (bruyamment) ton cas auprès du fournisseur de
compilateur (car il n'est pas conforme à la norme.) Si la condition est
vérifiée (cas de tes compilateurs non-conformes), tu auras par la suite un
"__func__" reconstruit (à __FUNCTION__ OU __FUNC__), à charge pour toi de
faire du mieux possible (test sur le numéro de version etc.) pour trouver un
remplaçant adapté.
Attention évidemment à ne pas tester par #if la #définition de __FUNCTION__
(ou de __func__, ou de n'importe quoi de similaire) hors d'un contexte de
fonction, car certains compilateurs vont effectivement faire la moue...
Autrement dit, il est sous-entendu que le morceau de code en direct
d'internet que tu as montré doit se trouver à l'*intérieur* d'une fonction,
peu importe que cette fonction soit utile, ou appelée, elle ne sert qu'à
établir le bon environnement pour les compilateurs.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
?
C>type func.c
int printf(const char*, ...);
const char *dehors = __FUNCTION__;
int main() {
const char *ici=__FUNCTION__;
printf("ici=<%s>, dehors=<%s>;n", ici, dehors);
return 0; }
C>gcc -o gcc -W -Wall func.c
C>cl func.c
Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
func.c
func.c(3) : error C2457: '__FUNCTION__': predefined macro cannot appear
outside
of a function body
Autrement dit, certes gcc accepte sans broncher la construction douteuse,
mais (une version pas spécialement récente) de VC tousse violement.Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
Et c'est là que j'ai du mal.
Pour afficher la pile d'appel (un concept dynamique), il faut un outil
dynamique (normalement, les cadres de pile), donc ce ne peut pas être fait
seulement avec des outils statiques (= dépendent du seul compilateur) comme
peut l'être __func__ (ou __FUNCTION__ etc.)
La solution classique fait appel à un déboggeur post-mortem (core,
Dump/Minidump), lequel utilise pour ce faire des fichiers spéciaux (les «
symboles de débogage », Dwarf/PDB) qui font la liaison entre les adresses
d'exécution et les noms de fonction (et des tas d'autres
choses.)Malheureusement, il n'y a guère de standards inter-plateforme à ce
niveau, mais un embryon de réponse peut se trouver au niveau des fichiers de
sortie de l'édition des liens (.map)
Mais la seule information du nom de la fonction est clairement
insuffisante...
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
Je persiste à ne pas comprendre comment tu arrives à cette situation de
non-fonctionnement. En fait, si j'arrive efectivement à reproduire un cas
d'erreur (cf. supra, et ce sans utiliser __func__), il n'en est pas moins
que mon exemple est stupide (qui voudrait obtenir le nom d'une fonction dans
la définition d'une variable globale ?)
Peut-être un petit exemple avec les messages d'erreur obtenu m'aiderait à
comprendre un peu mieux.
Antoine
smu wrote:
smu wrote:
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
J'ai du mal à te suivre.
Tu définis conditionnellement __func__ (à __FUNCTION__ OU __FUNC__), la
condition étant que __STDC_VERSION__ soit inférieur à 199901L; si
__STDC_VERSION__ est supérieur à 199901L, *et* que __func__ ne se comporte
pas comme il faut, tu reportes (bruyamment) ton cas auprès du fournisseur de
compilateur (car il n'est pas conforme à la norme.) Si la condition est
vérifiée (cas de tes compilateurs non-conformes), tu auras par la suite un
"__func__" reconstruit (à __FUNCTION__ OU __FUNC__), à charge pour toi de
faire du mieux possible (test sur le numéro de version etc.) pour trouver un
remplaçant adapté.
Attention évidemment à ne pas tester par #if la #définition de __FUNCTION__
(ou de __func__, ou de n'importe quoi de similaire) hors d'un contexte de
fonction, car certains compilateurs vont effectivement faire la moue...
Autrement dit, il est sous-entendu que le morceau de code en direct
d'internet que tu as montré doit se trouver à l'*intérieur* d'une fonction,
peu importe que cette fonction soit utile, ou appelée, elle ne sert qu'à
établir le bon environnement pour les compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
?
C>type func.c
int printf(const char*, ...);
const char *dehors = __FUNCTION__;
int main() {
const char *ici=__FUNCTION__;
printf("ici=<%s>, dehors=<%s>;n", ici, dehors);
return 0; }
C>gcc -o gcc -W -Wall func.c
C>cl func.c
Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
func.c
func.c(3) : error C2457: '__FUNCTION__': predefined macro cannot appear
outside
of a function body
Autrement dit, certes gcc accepte sans broncher la construction douteuse,
mais (une version pas spécialement récente) de VC tousse violement.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
Et c'est là que j'ai du mal.
Pour afficher la pile d'appel (un concept dynamique), il faut un outil
dynamique (normalement, les cadres de pile), donc ce ne peut pas être fait
seulement avec des outils statiques (= dépendent du seul compilateur) comme
peut l'être __func__ (ou __FUNCTION__ etc.)
La solution classique fait appel à un déboggeur post-mortem (core,
Dump/Minidump), lequel utilise pour ce faire des fichiers spéciaux (les «
symboles de débogage », Dwarf/PDB) qui font la liaison entre les adresses
d'exécution et les noms de fonction (et des tas d'autres
choses.)Malheureusement, il n'y a guère de standards inter-plateforme à ce
niveau, mais un embryon de réponse peut se trouver au niveau des fichiers de
sortie de l'édition des liens (.map)
Mais la seule information du nom de la fonction est clairement
insuffisante...
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
Je persiste à ne pas comprendre comment tu arrives à cette situation de
non-fonctionnement. En fait, si j'arrive efectivement à reproduire un cas
d'erreur (cf. supra, et ce sans utiliser __func__), il n'en est pas moins
que mon exemple est stupide (qui voudrait obtenir le nom d'une fonction dans
la définition d'une variable globale ?)
Peut-être un petit exemple avec les messages d'erreur obtenu m'aiderait à
comprendre un peu mieux.
Antoine
smu wrote:smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
J'ai du mal à te suivre.
Tu définis conditionnellement __func__ (à __FUNCTION__ OU __FUNC__), la
condition étant que __STDC_VERSION__ soit inférieur à 199901L; si
__STDC_VERSION__ est supérieur à 199901L, *et* que __func__ ne se comporte
pas comme il faut, tu reportes (bruyamment) ton cas auprès du fournisseur de
compilateur (car il n'est pas conforme à la norme.) Si la condition est
vérifiée (cas de tes compilateurs non-conformes), tu auras par la suite un
"__func__" reconstruit (à __FUNCTION__ OU __FUNC__), à charge pour toi de
faire du mieux possible (test sur le numéro de version etc.) pour trouver un
remplaçant adapté.
Attention évidemment à ne pas tester par #if la #définition de __FUNCTION__
(ou de __func__, ou de n'importe quoi de similaire) hors d'un contexte de
fonction, car certains compilateurs vont effectivement faire la moue...
Autrement dit, il est sous-entendu que le morceau de code en direct
d'internet que tu as montré doit se trouver à l'*intérieur* d'une fonction,
peu importe que cette fonction soit utile, ou appelée, elle ne sert qu'à
établir le bon environnement pour les compilateurs.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
?
C>type func.c
int printf(const char*, ...);
const char *dehors = __FUNCTION__;
int main() {
const char *ici=__FUNCTION__;
printf("ici=<%s>, dehors=<%s>;n", ici, dehors);
return 0; }
C>gcc -o gcc -W -Wall func.c
C>cl func.c
Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
func.c
func.c(3) : error C2457: '__FUNCTION__': predefined macro cannot appear
outside
of a function body
Autrement dit, certes gcc accepte sans broncher la construction douteuse,
mais (une version pas spécialement récente) de VC tousse violement.Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
Et c'est là que j'ai du mal.
Pour afficher la pile d'appel (un concept dynamique), il faut un outil
dynamique (normalement, les cadres de pile), donc ce ne peut pas être fait
seulement avec des outils statiques (= dépendent du seul compilateur) comme
peut l'être __func__ (ou __FUNCTION__ etc.)
La solution classique fait appel à un déboggeur post-mortem (core,
Dump/Minidump), lequel utilise pour ce faire des fichiers spéciaux (les «
symboles de débogage », Dwarf/PDB) qui font la liaison entre les adresses
d'exécution et les noms de fonction (et des tas d'autres
choses.)Malheureusement, il n'y a guère de standards inter-plateforme à ce
niveau, mais un embryon de réponse peut se trouver au niveau des fichiers de
sortie de l'édition des liens (.map)
Mais la seule information du nom de la fonction est clairement
insuffisante...
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
Je persiste à ne pas comprendre comment tu arrives à cette situation de
non-fonctionnement. En fait, si j'arrive efectivement à reproduire un cas
d'erreur (cf. supra, et ce sans utiliser __func__), il n'en est pas moins
que mon exemple est stupide (qui voudrait obtenir le nom d'une fonction dans
la définition d'une variable globale ?)
Peut-être un petit exemple avec les messages d'erreur obtenu m'aiderait à
comprendre un peu mieux.
Antoine
smu wrote:smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
J'ai du mal à te suivre.
Tu définis conditionnellement __func__ (à __FUNCTION__ OU __FUNC__), la
condition étant que __STDC_VERSION__ soit inférieur à 199901L; si
__STDC_VERSION__ est supérieur à 199901L, *et* que __func__ ne se comporte
pas comme il faut, tu reportes (bruyamment) ton cas auprès du fournisseur de
compilateur (car il n'est pas conforme à la norme.) Si la condition est
vérifiée (cas de tes compilateurs non-conformes), tu auras par la suite un
"__func__" reconstruit (à __FUNCTION__ OU __FUNC__), à charge pour toi de
faire du mieux possible (test sur le numéro de version etc.) pour trouver un
remplaçant adapté.
Attention évidemment à ne pas tester par #if la #définition de __FUNCTION__
(ou de __func__, ou de n'importe quoi de similaire) hors d'un contexte de
fonction, car certains compilateurs vont effectivement faire la moue...
Autrement dit, il est sous-entendu que le morceau de code en direct
d'internet que tu as montré doit se trouver à l'*intérieur* d'une fonction,
peu importe que cette fonction soit utile, ou appelée, elle ne sert qu'à
établir le bon environnement pour les compilateurs.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
?
C>type func.c
int printf(const char*, ...);
const char *dehors = __FUNCTION__;
int main() {
const char *ici=__FUNCTION__;
printf("ici=<%s>, dehors=<%s>;n", ici, dehors);
return 0; }
C>gcc -o gcc -W -Wall func.c
C>cl func.c
Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
func.c
func.c(3) : error C2457: '__FUNCTION__': predefined macro cannot appear
outside
of a function body
Autrement dit, certes gcc accepte sans broncher la construction douteuse,
mais (une version pas spécialement récente) de VC tousse violement.Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
Et c'est là que j'ai du mal.
Pour afficher la pile d'appel (un concept dynamique), il faut un outil
dynamique (normalement, les cadres de pile), donc ce ne peut pas être fait
seulement avec des outils statiques (= dépendent du seul compilateur) comme
peut l'être __func__ (ou __FUNCTION__ etc.)
La solution classique fait appel à un déboggeur post-mortem (core,
Dump/Minidump), lequel utilise pour ce faire des fichiers spéciaux (les «
symboles de débogage », Dwarf/PDB) qui font la liaison entre les adresses
d'exécution et les noms de fonction (et des tas d'autres
choses.)Malheureusement, il n'y a guère de standards inter-plateforme à ce
niveau, mais un embryon de réponse peut se trouver au niveau des fichiers de
sortie de l'édition des liens (.map)
Mais la seule information du nom de la fonction est clairement
insuffisante...
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
Je persiste à ne pas comprendre comment tu arrives à cette situation de
non-fonctionnement. En fait, si j'arrive efectivement à reproduire un cas
d'erreur (cf. supra, et ce sans utiliser __func__), il n'en est pas moins
que mon exemple est stupide (qui voudrait obtenir le nom d'une fonction dans
la définition d'une variable globale ?)
Peut-être un petit exemple avec les messages d'erreur obtenu m'aiderait à
comprendre un peu mieux.
Antoine
smu wrote:
smu wrote:
J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
J'ai du mal à te suivre.
Tu définis conditionnellement __func__ (à __FUNCTION__ OU __FUNC__), la
condition étant que __STDC_VERSION__ soit inférieur à 199901L; si
__STDC_VERSION__ est supérieur à 199901L, *et* que __func__ ne se comporte
pas comme il faut, tu reportes (bruyamment) ton cas auprès du fournisseur de
compilateur (car il n'est pas conforme à la norme.) Si la condition est
vérifiée (cas de tes compilateurs non-conformes), tu auras par la suite un
"__func__" reconstruit (à __FUNCTION__ OU __FUNC__), à charge pour toi de
faire du mieux possible (test sur le numéro de version etc.) pour trouver un
remplaçant adapté.
Attention évidemment à ne pas tester par #if la #définition de __FUNCTION__
(ou de __func__, ou de n'importe quoi de similaire) hors d'un contexte de
fonction, car certains compilateurs vont effectivement faire la moue...
Autrement dit, il est sous-entendu que le morceau de code en direct
d'internet que tu as montré doit se trouver à l'*intérieur* d'une fonction,
peu importe que cette fonction soit utile, ou appelée, elle ne sert qu'à
établir le bon environnement pour les compilateurs.
Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>
Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
?
C>type func.c
int printf(const char*, ...);
const char *dehors = __FUNCTION__;
int main() {
const char *ici=__FUNCTION__;
printf("ici=<%s>, dehors=<%s>;n", ici, dehors);
return 0; }
C>gcc -o gcc -W -Wall func.c
C>cl func.c
Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
func.c
func.c(3) : error C2457: '__FUNCTION__': predefined macro cannot appear
outside
of a function body
Autrement dit, certes gcc accepte sans broncher la construction douteuse,
mais (une version pas spécialement récente) de VC tousse violement.
Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
Et c'est là que j'ai du mal.
Pour afficher la pile d'appel (un concept dynamique), il faut un outil
dynamique (normalement, les cadres de pile), donc ce ne peut pas être fait
seulement avec des outils statiques (= dépendent du seul compilateur) comme
peut l'être __func__ (ou __FUNCTION__ etc.)
La solution classique fait appel à un déboggeur post-mortem (core,
Dump/Minidump), lequel utilise pour ce faire des fichiers spéciaux (les «
symboles de débogage », Dwarf/PDB) qui font la liaison entre les adresses
d'exécution et les noms de fonction (et des tas d'autres
choses.)Malheureusement, il n'y a guère de standards inter-plateforme à ce
niveau, mais un embryon de réponse peut se trouver au niveau des fichiers de
sortie de l'édition des liens (.map)
Mais la seule information du nom de la fonction est clairement
insuffisante...
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
Je persiste à ne pas comprendre comment tu arrives à cette situation de
non-fonctionnement. En fait, si j'arrive efectivement à reproduire un cas
d'erreur (cf. supra, et ce sans utiliser __func__), il n'en est pas moins
que mon exemple est stupide (qui voudrait obtenir le nom d'une fonction dans
la définition d'une variable globale ?)
Peut-être un petit exemple avec les messages d'erreur obtenu m'aiderait à
comprendre un peu mieux.
Antoine
smu wrote:smu wrote:J'ai une API qui est compilé sur différentes plate-formes avec
différents compilateurs.
Hmmm, comme le fait remarquer Marc, si tu utilises du C99 (__func__)
sur de multiples compilateurs, tu devrais te proteger avec
__STDC_VERSION__... mais bon c'est du cosmétique.
Le problème est que je suis en présence de multiples compilateurs qui
ne sont pas tous conforme au standard C99.
J'ai du mal à te suivre.
Tu définis conditionnellement __func__ (à __FUNCTION__ OU __FUNC__), la
condition étant que __STDC_VERSION__ soit inférieur à 199901L; si
__STDC_VERSION__ est supérieur à 199901L, *et* que __func__ ne se comporte
pas comme il faut, tu reportes (bruyamment) ton cas auprès du fournisseur de
compilateur (car il n'est pas conforme à la norme.) Si la condition est
vérifiée (cas de tes compilateurs non-conformes), tu auras par la suite un
"__func__" reconstruit (à __FUNCTION__ OU __FUNC__), à charge pour toi de
faire du mieux possible (test sur le numéro de version etc.) pour trouver un
remplaçant adapté.
Attention évidemment à ne pas tester par #if la #définition de __FUNCTION__
(ou de __func__, ou de n'importe quoi de similaire) hors d'un contexte de
fonction, car certains compilateurs vont effectivement faire la moue...
Autrement dit, il est sous-entendu que le morceau de code en direct
d'internet que tu as montré doit se trouver à l'*intérieur* d'une fonction,
peu importe que cette fonction soit utile, ou appelée, elle ne sert qu'à
établir le bon environnement pour les compilateurs.Afin de tracer l'usage de l'API chez nos clients (en déverminage),
j'ai utilisé une macro que j'avais trouvé sur la toile :
<couic>Je viens de me rendre compte d'un problème, __func__ semble n'être
valide que dans la fonction
Euh oui, le nom de la fonction en cours de définition n'est
accessible qu'à l'intérieur de la définition ; quand on y réfléchit,
on a du mal à voir comment faire autrement, d'ailleurs.
Vu la déclaration sous-jacente, je comprends bien le problème de la
portée de l'identifiant __func__. Toutefois, la macro __FUNCTION__ de
GNU C et de Microsoft C n'était pas soumis à ce problème.
?
C>type func.c
int printf(const char*, ...);
const char *dehors = __FUNCTION__;
int main() {
const char *ici=__FUNCTION__;
printf("ici=<%s>, dehors=<%s>;n", ici, dehors);
return 0; }
C>gcc -o gcc -W -Wall func.c
C>cl func.c
Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
func.c
func.c(3) : error C2457: '__FUNCTION__': predefined macro cannot appear
outside
of a function body
Autrement dit, certes gcc accepte sans broncher la construction douteuse,
mais (une version pas spécialement récente) de VC tousse violement.Du coup, je recherche une solution pour remplacer la macro initiale.
Peut-être pourrais-tu exprimer le besoin que tu cherches à combler
(imprimer quoi, dans quel contexte, dans quelles conditions le
problème se manifeste = où la solution actuelle plante-t-elle et
comment ?)
Le besoin est simple : afficher la pile d'appel lorsqu'une erreur se
produit.
Et c'est là que j'ai du mal.
Pour afficher la pile d'appel (un concept dynamique), il faut un outil
dynamique (normalement, les cadres de pile), donc ce ne peut pas être fait
seulement avec des outils statiques (= dépendent du seul compilateur) comme
peut l'être __func__ (ou __FUNCTION__ etc.)
La solution classique fait appel à un déboggeur post-mortem (core,
Dump/Minidump), lequel utilise pour ce faire des fichiers spéciaux (les «
symboles de débogage », Dwarf/PDB) qui font la liaison entre les adresses
d'exécution et les noms de fonction (et des tas d'autres
choses.)Malheureusement, il n'y a guère de standards inter-plateforme à ce
niveau, mais un embryon de réponse peut se trouver au niveau des fichiers de
sortie de l'édition des liens (.map)
Mais la seule information du nom de la fonction est clairement
insuffisante...
La solution actuelle (voir macro) ne fonctionne pas puisque __func__
n'est pas défini à cet instant.
Je persiste à ne pas comprendre comment tu arrives à cette situation de
non-fonctionnement. En fait, si j'arrive efectivement à reproduire un cas
d'erreur (cf. supra, et ce sans utiliser __func__), il n'en est pas moins
que mon exemple est stupide (qui voudrait obtenir le nom d'une fonction dans
la définition d'une variable globale ?)
Peut-être un petit exemple avec les messages d'erreur obtenu m'aiderait à
comprendre un peu mieux.
Antoine
Peut-être un petit exemple avec les messages d'erreur obtenu
m'aiderait à comprendre un peu mieux.
L'exemple suivant fonctionne très bien avec VS 2003 (L2) parce que
__FUNCTION__ existe même s'il renvoie qu'une chaîne vide :
#include <stdio.h>
#define __label__ "L1"
#ifndef __func__
Peut-être un petit exemple avec les messages d'erreur obtenu
m'aiderait à comprendre un peu mieux.
L'exemple suivant fonctionne très bien avec VS 2003 (L2) parce que
__FUNCTION__ existe même s'il renvoie qu'une chaîne vide :
#include <stdio.h>
#define __label__ "L1"
#ifndef __func__
Peut-être un petit exemple avec les messages d'erreur obtenu
m'aiderait à comprendre un peu mieux.
L'exemple suivant fonctionne très bien avec VS 2003 (L2) parce que
__FUNCTION__ existe même s'il renvoie qu'une chaîne vide :
#include <stdio.h>
#define __label__ "L1"
#ifndef __func__