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 :
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__[];'').
Du coup, je recherche une solution pour remplacer la macro initiale.
D'avance merci pour tout élément qui ferait avancé le schmilblick.
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 :
Je ne suis pas sûr de bien comprendre tes messages. Jusqu'à maintenant, j'ai vu un morceau de code qui, selon toi, marche. Et des récriminations comme quoi « __func__ n'est pas défini », sans précision du compilateur.
#include <stdio.h>
#define __label__ "L1" #ifndef __func__
Ajoute _avant_ cette ligne:
#if __STDC_VERSION__>9901L && !defined __func__ #define __func__ __func__ /* Rend le __func__ interne d'un compilo * C99 visible depuis le préprocesseur */ #endif
Cela devrait permettre à ton code existant de passer plus ou moins sur un compilo C99. Mais il n'en reste pas moins que la logique de test, au travers du préprocesseur, d'une fonctionnalité qui n'en dépend pas (le préprocesseur passe _avant_ que le translateur ne découpe le source en fonction) montre un problème de logique de conception. Je ne serais pas surpris que des compilateurs un peu pointilleux ne grognent (avertissement) sur le code ci-dessus; de la même façon que d'écrire #define int int n'est pas un vrai problème dans la pratique, mais cela ne paraît pas très propre non plus.
Antoine
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise, * j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes, * à la limite, le fait d'être conforme au C99 n'est pas mon problème dans le sens où ce qui est conforme n'est pas forcément portable et ce qui est portable n'est pas forcément conforme (en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et * on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Sachant que le but est d'écrire un code le plus propre possible.
smu
smu wrote:
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 :
Je ne suis pas sûr de bien comprendre tes messages. Jusqu'à maintenant, j'ai
vu un morceau de code qui, selon toi, marche. Et des récriminations comme
quoi « __func__ n'est pas défini », sans précision du compilateur.
#include <stdio.h>
#define __label__ "L1"
#ifndef __func__
Ajoute _avant_ cette ligne:
#if __STDC_VERSION__>9901L && !defined __func__
#define __func__ __func__ /* Rend le __func__ interne d'un compilo
* C99 visible depuis le préprocesseur */
#endif
Cela devrait permettre à ton code existant de passer plus ou moins sur un
compilo C99. Mais il n'en reste pas moins que la logique de test, au travers
du préprocesseur, d'une fonctionnalité qui n'en dépend pas (le préprocesseur
passe _avant_ que le translateur ne découpe le source en fonction) montre un
problème de logique de conception. Je ne serais pas surpris que des
compilateurs un peu pointilleux ne grognent (avertissement) sur le code
ci-dessus; de la même façon que d'écrire
#define int int
n'est pas un vrai problème dans la pratique, mais cela ne paraît pas très
propre non plus.
Antoine
Remettons le problème à plat :
* le code que j'écris peut être compilé sur différentes plate-formes et
avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise,
* j'ai besoin de connaître les enchaînements de fonctions de l'API afin
de vérifier si le client ne s'est pas trompé dans la commande des cartes,
* à la limite, le fait d'être conforme au C99 n'est pas mon problème
dans le sens où ce qui est conforme n'est pas forcément portable et ce
qui est portable n'est pas forcément conforme (en gardant à l'esprit le
fait que je ne connaisse pas les compilateurs des clients) et
* on développe des cartes pour les vendre, l'API livré sous forme de
code n'est là que pour exploiter le matériel.
Sachant que le but est d'écrire un code le plus propre possible.
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 :
Je ne suis pas sûr de bien comprendre tes messages. Jusqu'à maintenant, j'ai vu un morceau de code qui, selon toi, marche. Et des récriminations comme quoi « __func__ n'est pas défini », sans précision du compilateur.
#include <stdio.h>
#define __label__ "L1" #ifndef __func__
Ajoute _avant_ cette ligne:
#if __STDC_VERSION__>9901L && !defined __func__ #define __func__ __func__ /* Rend le __func__ interne d'un compilo * C99 visible depuis le préprocesseur */ #endif
Cela devrait permettre à ton code existant de passer plus ou moins sur un compilo C99. Mais il n'en reste pas moins que la logique de test, au travers du préprocesseur, d'une fonctionnalité qui n'en dépend pas (le préprocesseur passe _avant_ que le translateur ne découpe le source en fonction) montre un problème de logique de conception. Je ne serais pas surpris que des compilateurs un peu pointilleux ne grognent (avertissement) sur le code ci-dessus; de la même façon que d'écrire #define int int n'est pas un vrai problème dans la pratique, mais cela ne paraît pas très propre non plus.
Antoine
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise, * j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes, * à la limite, le fait d'être conforme au C99 n'est pas mon problème dans le sens où ce qui est conforme n'est pas forcément portable et ce qui est portable n'est pas forcément conforme (en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et * on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Sachant que le but est d'écrire un code le plus propre possible.
smu
espie
In article <et94gv$j59$, smu wrote:
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise, * j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes, * à la limite, le fait d'être conforme au C99 n'est pas mon problème dans le sens où ce qui est conforme n'est pas forcément portable et ce qui est portable n'est pas forcément conforme (en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et * on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Dialogue de sourds... ce qu'on te repete depuis n messages, c'est: * __func__ est maintenant une API standard, conforme a la norme C99. * il y a moyen d'interroger le systeme pour savoir si celui-ci est conforme a la norme C99.
On te donne une strategie simple: - soit ton systeme est C99: rien a faire, ca marche (et en plus, tu sais que tu es dasn ce cas). - soit tu tombes sur un autre cas: tu as deja les tests `legacy' qui vont bien.
On ne focalise absolument pas sur le cote standard, gnagnagna. On te dit JUSTE que dans ce cas precis, la norme prescrit un comportement defini, connu et sense qui doit te permettre de regler le cas de 95% des compilateurs recents.
Et tu as deja le code de gestion des exceptions anterieures.
Qu'est-ce que tu veux de plus ?
In article <et94gv$j59$1@s1.news.oleane.net>, smu <pas@d.adresse> wrote:
Remettons le problème à plat :
* le code que j'écris peut être compilé sur différentes plate-formes et
avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise,
* j'ai besoin de connaître les enchaînements de fonctions de l'API afin
de vérifier si le client ne s'est pas trompé dans la commande des cartes,
* à la limite, le fait d'être conforme au C99 n'est pas mon problème
dans le sens où ce qui est conforme n'est pas forcément portable et ce
qui est portable n'est pas forcément conforme (en gardant à l'esprit le
fait que je ne connaisse pas les compilateurs des clients) et
* on développe des cartes pour les vendre, l'API livré sous forme de
code n'est là que pour exploiter le matériel.
Dialogue de sourds... ce qu'on te repete depuis n messages, c'est:
* __func__ est maintenant une API standard, conforme a la norme C99.
* il y a moyen d'interroger le systeme pour savoir si celui-ci est conforme
a la norme C99.
On te donne une strategie simple:
- soit ton systeme est C99: rien a faire, ca marche (et en plus, tu sais
que tu es dasn ce cas).
- soit tu tombes sur un autre cas: tu as deja les tests `legacy' qui vont
bien.
On ne focalise absolument pas sur le cote standard, gnagnagna. On te dit
JUSTE que dans ce cas precis, la norme prescrit un comportement defini,
connu et sense qui doit te permettre de regler le cas de 95% des compilateurs
recents.
Et tu as deja le code de gestion des exceptions anterieures.
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise, * j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes, * à la limite, le fait d'être conforme au C99 n'est pas mon problème dans le sens où ce qui est conforme n'est pas forcément portable et ce qui est portable n'est pas forcément conforme (en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et * on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Dialogue de sourds... ce qu'on te repete depuis n messages, c'est: * __func__ est maintenant une API standard, conforme a la norme C99. * il y a moyen d'interroger le systeme pour savoir si celui-ci est conforme a la norme C99.
On te donne une strategie simple: - soit ton systeme est C99: rien a faire, ca marche (et en plus, tu sais que tu es dasn ce cas). - soit tu tombes sur un autre cas: tu as deja les tests `legacy' qui vont bien.
On ne focalise absolument pas sur le cote standard, gnagnagna. On te dit JUSTE que dans ce cas precis, la norme prescrit un comportement defini, connu et sense qui doit te permettre de regler le cas de 95% des compilateurs recents.
Et tu as deja le code de gestion des exceptions anterieures.
Qu'est-ce que tu veux de plus ?
Antoine Leca
smu écrivit:
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise,
Oui.
* j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes,
D'accord.
* à la limite, le fait d'être conforme au C99 n'est pas mon problème
Certes (c'est juste une solution).
dans le sens où ce qui est conforme n'est pas forcément portable
Pas d'accord.
et ce qui est portable n'est pas forcément conforme
Oh oui.
(en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et
Oui.
* on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Certes.
Sachant que le but est d'écrire un code le plus propre possible.
Bien. Arrivé là, je n'ai toujours pas compris ton problème. Désolé. Soit c'est pour une diatribe contre la norme C99 (désolé, mais c'est ce à quoi ce fil ressemble le plus jusqu'à maintenant), et dans tous les cas ce n'est pas constructif, comme d'habitude avec les flame war. Soit tu veux réorganiser ton code pour le rendre plus facilement maintenable (louable intention), et tu penses que la solution est de faire l'impasse sur C99 ce en quoi je ne suis pas d'accord (brisons-là, je ne vais pas en remettre une couche). Soit tu penses que tu pourrais avoir un problème avec un compilateur non identifié pour un problème de portabilité ou de mauvaise conformité de ton code (cela est fréquent lorsqu'on cherche à améliorer la portabilité d'un programme; mais ce que tu écris ci-dessus me laisse pense que ce n'est pas le cas), et alors j'essaye d'indiquer les zones du code que tu as publié où, à mon sens, il faudrait faire porter un effort d'étude plus approfondie. Soit tu as réellement un problème avec un morceau de code qui ne passe pas ou passe mal sur une certaine plateforme, et alors j'essaye de comprendre quel est ce morceau de code et quelle est cette plateforme, afin par exemple d'essayer de reproduire le problème pour trouver une éventuelle solution. Dans l'intervalle, je (et Marc) proposons des pistes de solution (__STDC_VERSION__), tout en montrant en même temps les limites inhérentes à nos solutions pour t'éviter de perdre du temps et pour te permettre d'essayer d'avancer le plus vite possible dans la « bonne » direction.
Antoine
smu écrivit:
Remettons le problème à plat :
* le code que j'écris peut être compilé sur différentes plate-formes
et avec différents compilateurs, chose sur laquelle je n'ai aucune
maîtrise,
Oui.
* j'ai besoin de connaître les enchaînements de fonctions de l'API
afin de vérifier si le client ne s'est pas trompé dans la commande des
cartes,
D'accord.
* à la limite, le fait d'être conforme au C99 n'est pas mon problème
Certes (c'est juste une solution).
dans le sens où ce qui est conforme n'est pas forcément portable
Pas d'accord.
et ce qui est portable n'est pas forcément conforme
Oh oui.
(en gardant à l'esprit le fait que je ne connaisse pas les
compilateurs des clients) et
Oui.
* on développe des cartes pour les vendre, l'API livré sous forme de
code n'est là que pour exploiter le matériel.
Certes.
Sachant que le but est d'écrire un code le plus propre possible.
Bien.
Arrivé là, je n'ai toujours pas compris ton problème.
Désolé.
Soit c'est pour une diatribe contre la norme C99 (désolé, mais c'est ce à
quoi ce fil ressemble le plus jusqu'à maintenant), et dans tous les cas ce
n'est pas constructif, comme d'habitude avec les flame war.
Soit tu veux réorganiser ton code pour le rendre plus facilement maintenable
(louable intention), et tu penses que la solution est de faire l'impasse sur
C99 ce en quoi je ne suis pas d'accord (brisons-là, je ne vais pas en
remettre une couche).
Soit tu penses que tu pourrais avoir un problème avec un compilateur non
identifié pour un problème de portabilité ou de mauvaise conformité de ton
code (cela est fréquent lorsqu'on cherche à améliorer la portabilité d'un
programme; mais ce que tu écris ci-dessus me laisse pense que ce n'est pas
le cas), et alors j'essaye d'indiquer les zones du code que tu as publié où,
à mon sens, il faudrait faire porter un effort d'étude plus approfondie.
Soit tu as réellement un problème avec un morceau de code qui ne passe pas
ou passe mal sur une certaine plateforme, et alors j'essaye de comprendre
quel est ce morceau de code et quelle est cette plateforme, afin par exemple
d'essayer de reproduire le problème pour trouver une éventuelle solution.
Dans l'intervalle, je (et Marc) proposons des pistes de solution
(__STDC_VERSION__), tout en montrant en même temps les limites inhérentes à
nos solutions pour t'éviter de perdre du temps et pour te permettre
d'essayer d'avancer le plus vite possible dans la « bonne » direction.
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise,
Oui.
* j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes,
D'accord.
* à la limite, le fait d'être conforme au C99 n'est pas mon problème
Certes (c'est juste une solution).
dans le sens où ce qui est conforme n'est pas forcément portable
Pas d'accord.
et ce qui est portable n'est pas forcément conforme
Oh oui.
(en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et
Oui.
* on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Certes.
Sachant que le but est d'écrire un code le plus propre possible.
Bien. Arrivé là, je n'ai toujours pas compris ton problème. Désolé. Soit c'est pour une diatribe contre la norme C99 (désolé, mais c'est ce à quoi ce fil ressemble le plus jusqu'à maintenant), et dans tous les cas ce n'est pas constructif, comme d'habitude avec les flame war. Soit tu veux réorganiser ton code pour le rendre plus facilement maintenable (louable intention), et tu penses que la solution est de faire l'impasse sur C99 ce en quoi je ne suis pas d'accord (brisons-là, je ne vais pas en remettre une couche). Soit tu penses que tu pourrais avoir un problème avec un compilateur non identifié pour un problème de portabilité ou de mauvaise conformité de ton code (cela est fréquent lorsqu'on cherche à améliorer la portabilité d'un programme; mais ce que tu écris ci-dessus me laisse pense que ce n'est pas le cas), et alors j'essaye d'indiquer les zones du code que tu as publié où, à mon sens, il faudrait faire porter un effort d'étude plus approfondie. Soit tu as réellement un problème avec un morceau de code qui ne passe pas ou passe mal sur une certaine plateforme, et alors j'essaye de comprendre quel est ce morceau de code et quelle est cette plateforme, afin par exemple d'essayer de reproduire le problème pour trouver une éventuelle solution. Dans l'intervalle, je (et Marc) proposons des pistes de solution (__STDC_VERSION__), tout en montrant en même temps les limites inhérentes à nos solutions pour t'éviter de perdre du temps et pour te permettre d'essayer d'avancer le plus vite possible dans la « bonne » direction.
Antoine
smu
In article <et94gv$j59$, smu wrote:
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise, * j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes, * à la limite, le fait d'être conforme au C99 n'est pas mon problème dans le sens où ce qui est conforme n'est pas forcément portable et ce qui est portable n'est pas forcément conforme (en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et * on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Dialogue de sourds... ce qu'on te repete depuis n messages, c'est: * __func__ est maintenant une API standard, conforme a la norme C99. * il y a moyen d'interroger le systeme pour savoir si celui-ci est conforme a la norme C99.
On te donne une strategie simple: - soit ton systeme est C99: rien a faire, ca marche (et en plus, tu sais que tu es dasn ce cas). - soit tu tombes sur un autre cas: tu as deja les tests `legacy' qui vont bien.
On ne focalise absolument pas sur le cote standard, gnagnagna. On te dit JUSTE que dans ce cas precis, la norme prescrit un comportement defini, connu et sense qui doit te permettre de regler le cas de 95% des compilateurs recents.
Et tu as deja le code de gestion des exceptions anterieures.
Qu'est-ce que tu veux de plus ?
Pour info, votre réponse du 12/03/2007 à 14:49 me convenait très bien. Et on aurait très bien pu en rester là...
Au faite, merci
smu
In article <et94gv$j59$1@s1.news.oleane.net>, smu <pas@d.adresse> wrote:
Remettons le problème à plat :
* le code que j'écris peut être compilé sur différentes plate-formes et
avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise,
* j'ai besoin de connaître les enchaînements de fonctions de l'API afin
de vérifier si le client ne s'est pas trompé dans la commande des cartes,
* à la limite, le fait d'être conforme au C99 n'est pas mon problème
dans le sens où ce qui est conforme n'est pas forcément portable et ce
qui est portable n'est pas forcément conforme (en gardant à l'esprit le
fait que je ne connaisse pas les compilateurs des clients) et
* on développe des cartes pour les vendre, l'API livré sous forme de
code n'est là que pour exploiter le matériel.
Dialogue de sourds... ce qu'on te repete depuis n messages, c'est:
* __func__ est maintenant une API standard, conforme a la norme C99.
* il y a moyen d'interroger le systeme pour savoir si celui-ci est conforme
a la norme C99.
On te donne une strategie simple:
- soit ton systeme est C99: rien a faire, ca marche (et en plus, tu sais
que tu es dasn ce cas).
- soit tu tombes sur un autre cas: tu as deja les tests `legacy' qui vont
bien.
On ne focalise absolument pas sur le cote standard, gnagnagna. On te dit
JUSTE que dans ce cas precis, la norme prescrit un comportement defini,
connu et sense qui doit te permettre de regler le cas de 95% des compilateurs
recents.
Et tu as deja le code de gestion des exceptions anterieures.
Qu'est-ce que tu veux de plus ?
Pour info, votre réponse du 12/03/2007 à 14:49 me convenait très bien.
Et on aurait très bien pu en rester là...
Remettons le problème à plat : * le code que j'écris peut être compilé sur différentes plate-formes et avec différents compilateurs, chose sur laquelle je n'ai aucune maîtrise, * j'ai besoin de connaître les enchaînements de fonctions de l'API afin de vérifier si le client ne s'est pas trompé dans la commande des cartes, * à la limite, le fait d'être conforme au C99 n'est pas mon problème dans le sens où ce qui est conforme n'est pas forcément portable et ce qui est portable n'est pas forcément conforme (en gardant à l'esprit le fait que je ne connaisse pas les compilateurs des clients) et * on développe des cartes pour les vendre, l'API livré sous forme de code n'est là que pour exploiter le matériel.
Dialogue de sourds... ce qu'on te repete depuis n messages, c'est: * __func__ est maintenant une API standard, conforme a la norme C99. * il y a moyen d'interroger le systeme pour savoir si celui-ci est conforme a la norme C99.
On te donne une strategie simple: - soit ton systeme est C99: rien a faire, ca marche (et en plus, tu sais que tu es dasn ce cas). - soit tu tombes sur un autre cas: tu as deja les tests `legacy' qui vont bien.
On ne focalise absolument pas sur le cote standard, gnagnagna. On te dit JUSTE que dans ce cas precis, la norme prescrit un comportement defini, connu et sense qui doit te permettre de regler le cas de 95% des compilateurs recents.
Et tu as deja le code de gestion des exceptions anterieures.
Qu'est-ce que tu veux de plus ?
Pour info, votre réponse du 12/03/2007 à 14:49 me convenait très bien. Et on aurait très bien pu en rester là...
