[PREPROCESSEUR] quelle difference ??

salut j'ai une simple (encore une) question
si j'ecris

Code:

---

1 2 3 4 5 6 7 8

#define LOG 0   #if LOG #define _LOG(text,params) STLOG_WRITE(text,params) #else #define _LOG(text,params) #endif

---

je peu choisir si je log ou pas certaines chose, si je met
#define LOG 1 ça trace
#define LOG0 ça trace pas

Mais il me vient une question dans le cas LOG = 0
le compilo met quoi a la place de ma macro _LOG(text,params) ???

En cherchant j'ai trouver des gens qui faisaient

Code:

---

1 2 3 4 5 6 7 8 9

#define LOG 0   #if LOG #define _LOG(text,params) STLOG_WRITE(text,params) #else #define _LOG(text,params) / inline doNothin(){} #endif

---

Ma question est : quel est le plus propre et bein sur le plus "stable" il me sembke quand meme que la solution inline donne l'assurance d'avoir quelque chose dans les deux cas !!
Mais f(){} c'est compilé, linké et présent dans l'exe ???
le compilo fait le menage non ? alors quel interet de mettre une fonction inline dans ce cas ??

Salut,

Dans le même genre, j'avais trouvé sur un site du genre GameDev une version des outils de debug type MFC pour insérer dans un projet non-MFC, et ça donnait ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#ifndef __DEBUG_H__ #define __DEBUG_H__   #ifdef _DEBUG   #define ASSERT(x) { if (!(x)) _asm{int 0x03} } #define VERIFY(x) { if (!(x)) _asm{int 0x03} }   void _trace(char *fmt, ...); #define TRACE _trace   #else   #define ASSERT(x) #define VERIFY(x) x   inline void _trace(char* fmt, ...) { } #define TRACE 1 ? (void)0 : _trace   #endif   #endif // __DEBUG_H__

---

(sachant que void _trace(char *fmt, ...); est défini dans le .cpp correspondant bien sûr...)

Ma question est la même je pense, à quoi sert:

Code:

---

1 2	inline void _trace(char* fmt, ...) { } #define TRACE 1 ? (void)0 : _trace

---

est ce que, comme pour ASSERT un simple

Code:

---

1 2 3

#define TRACE(x) ou encore inline void TRACE(char* fmt, ...) { }

---

n'aurait pas suffi ?

Voilà voilà, ça m'intrigue aussi cette histoire ;)

Citation:

---

le compilo met quoi a la place de ma macro _LOG(text,params) ???

---

Absolument rien.

Citation:

---

Mais f(){} c'est compilé, linké et présent dans l'exe ???
le compilo fait le menage non ? alors quel interet de mettre une fonction inline dans ce cas ??

---

Avec un minimum d'optimisations, je pense que le ocmpilo fait effectivement le ménage. En ce qui concerne ton code, il est truffé de fautes et le principe en lui-même est douteux. Si tu l'as trouvé tel quel alors il n'a jamais été testé, sinon donne le vrai.

Citation:

---

est ce que, comme pour ASSERT un simple

Code:

---

1 2 3

#define TRACE(x) ou encore inline void TRACE(char* fmt, ...){}

---

n'aurait pas suffi ?

---

Non, car cette macro ne prend pas de paramètres. En fait elle ne pourrait pas, car il y a utilisation de l'ellipse (...) pour spécifier un nombre variable d'arguments. Or, il n'existe aucun moyen de construire une macro à arguments variables.

En gros cela donnerait ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// Code original TRACE("Salut %s", "Bob");   // En debug _trace("Salut %s", "Bob");   // En release _trace("Salut %s", "Bob"); // mais _trace est vide - ce sera viré par le compilo   // Ton idée ("Salut %s", "Bob"); // ça compilera pas beaucoup :)

---

Un autre cas dans lequel il faut définir une fonction inline, c'est lorsqu'on doit évaluer le paramètre de la macro quoiqu'il arrive

Code:

---

assert(fichier.open("toto.txt"));

---

Si on remplace assert par que dalle en mode release, le fichier ne sera pas ouvert.

Citation:

---

Citation:

---

Mais f(){} c'est compilé, linké et présent dans l'exe ???
le compilo fait le menage non ? alors quel interet de mettre une fonction inline dans ce cas ??

---

Avec un minimum d'optimisations, je pense que le ocmpilo fait effectivement le ménage. En ce qui concerne ton code, il est truffé de fautes et le principe en lui-même est douteux. Si tu l'as trouvé tel quel alors il n'a jamais été testé, sinon donne le vrai.

---

voici le vrai code :

Code:

---

1 2 3 4 5 6 7 8 9

#ifdef STLOG_PRINT_COMPILE_INFO #define STLOG_EXPAND_INFO(file, line) \ CURRENT_FILE = file; CURRENT_LINE=line; #else inline void _______DoNothing0() {}; #define STLOG_EXPAND_INFO(file, line) \ 1 ? void(0) : _______DoNothing0(); #endif

---

c'est chian a lire c'est pour ça que j'ai mi un vague apperçu desolé ;)
Mais le pourquoi rest e obscure quand meme....
je vais rester avec ma premiere idee si le compilo met rien ça me va

EDIT :

Code:

---

1 2 3 4 5 6 7 8

#define LOG 0   #if LOG #define _LOG(text,params) STLOG_WRITE(text,params) #else #define _LOG(text,params) #endif

---

ya quelque chose qui te derange la dedans ??? :oops:

Citation:

---

Si on remplace assert par que dalle en mode release, le fichier ne sera pas ouvert.

---

OK, donc j'imagine que c'est pour ça qu'ils ont fait le VERIFY en plus du ASSERT ...

Par contre, il y a un truc que je ne comprends toujours pas :oops:

Citation:

---

Non, car cette macro ne prend pas de paramètres. En fait elle ne pourrait pas, car il y a utilisation de l'ellipse (...) pour spécifier un nombre variable d'arguments. Or, il n'existe aucun moyen de construire une macro à arguments variables.

---

ça c'est bon, finalement ça parait plutôt clair et évident une fois que tu l'as dit ;)

Mais pourquoi

Code:

---

1 2	inline void _trace(char* fmt, ...) { } #define TRACE 1 ? (void)0 : _trace

---

au lieu du simple

Code:

---

inline void TRACE(char* fmt, ...) { }

---

Est-ce qu'il y a une autre subtilité ?

Citation:

---

Code:

---

1 2 3 4 5 6 7

#define LOG 0   #if LOG #define _LOG(text,params) STLOG_WRITE(text,params) #else #define _LOG(text,params) #endif

---

ya quelque chose qui te derange la dedans ???

---

En fait après reflexion, je pense que c'est une mauvaise idée de ne rien mettre. Imagine cette instruction :

Code:

---

_LOG(x, y), _LOG(a, b);

---

C'est un peu n'importe quoi mais c'est valide. Et ce n'est sûrement pas le seul cas problèmatique.
Question à trois francs : sous quelle forme se présente le paramètre params ?

Citation:

---

Mais pourquoi

Code:

---

1 2	inline void _trace(char* fmt, ...) { } #define TRACE 1 ? (void)0 : _trace

---

au lieu du simple

Code:

---

inline void TRACE(char* fmt, ...) { }

---

Est-ce qu'il y a une autre subtilité ?

---

A priori non, mais j'imagine qu'il y en a tout de même une.

Par contre ce qui me choque, c'est tous ces opérateurs ternaires. Si quelqu'un a une explication...

c'est une entre d'ellipse....
je sais c'est mal mais c'est du log style

Code:

---

_LOG(TEXT("mon %d log"),1));

---

C'est tres pourri masi je voulais une macro qui puisse faire sauter les log facilement...
Si tu as une meilleur façon je suis preneur en fait !

J'ai du mal à voir comment tu fais passer un nombre variable de paramètres dans un seul paramètre de ta macro ?

A l'époque je faisais comme vu plus haut : une macro sans paramètre qui remplace juste le nom de la fonction. C'est moche, mais ma foi...

Le mieux est encore d'utiliser un logging style flux C++, avec opérateur <<.

En ce moment, j'utilise

Code:

---

1 2 3 4 5 6 7

LOG("Texte ")(hopUnInt)(" et aussi ")(hopUneString) (/*hop une cst*/42)(" et this pour finir: ")(this->toString()) .trace("balise pour le fichier de log") .alarm(niveau_de_criticite) // pour un composant qui // centralise les alarmes .exception<type_exception>() // si nécessaire ;

---

La syntaxe est certes un peu zarbi, mais au moins je n'ai aucun risque de me planter dans les formats, le texte est généré une fois pour toutes et redispatché ensuite à diverses fonctions.

Je suis parti de SMART_ASSERT présenté dans un article d'Andrei Alexandrescu qui est dispo sur le site du C/C++ Users Journal.

Citation:

---

Envoyé par Luc Hermitte

En ce moment, j'utilise

Code:

---

1 2 3 4 5 6 7

LOG("Texte ")(hopUnInt)(" et aussi ")(hopUneString) (/*hop une cst*/42)(" et this pour finir: ")(this->toString()) .trace("balise pour le fichier de log") .alarm(niveau_de_criticite) // pour un composant qui // centralise les alarmes .exception<type_exception>() // si nécessaire ;

---

La syntaxe est certes un peu zarbi, mais au moins je n'ai aucun risque de me planter dans les formats, le texte est généré une fois pour toutes et redispatché ensuite à diverses fonctions.

Je suis parti de SMART_ASSERT présenté dans un article d'Andrei Alexandrescu qui est dispo sur le site du C/C++ Users Journal.

---

waouuu paye ton truc !!! 8O je suppose que ça marche je vasi essayer de voir coment ça marche.... merci les gars

EDIT : C'est bon pour moi sur le sujet mais comme il y a d'autres question je la passe pas en [resolu] j'attends l'avis de bigquick

Pour moi c'est presque bon :)

La solution de Luc à l'air super complète, mais euh, voici le lien en question (ou un lien qui s'en rapproche en tout cas): http://www.cuj.com/documents/s=8464/...p0308alexandr/ ... c'est assez tendu :) Ca devrait plaire à Loulou24 je pense ;) (merci au passage pour tes tutoriaux sur la meta-programmation, j'essaye de comprendre tout ça petit à petit!)

Enfin donc n'ai pas trop compris comment ça fonctionne pour qu'en release le code compile tranquillement... En tout cas, ça à l'air bien compliqué de faire une belle classe de logs / trace / gestion d'erreur ....

ps: sinon toujours pas d'explication pour

Code:

---

1 2 3

#define TRACE 1 ? (void)0 : _trace #define STLOG_EXPAND_INFO(file, line) 1 ? void(0) : _DoNothing0();

---

mais bon, ça fonctionne, alors tant pis pour les subtilités :roll:

Citation:

---

Envoyé par bigquick

En tout cas, ça à l'air bien compliqué de faire une belle classe de logs / trace / gestion d'erreur ....

---

La dernière fois que j'avais vérifié, ils n'avaient toujours pas convergé chez boost. Même si le besoin avait été bel et bien ressenti et étudié.
Bref, le beau truc ultime n'est pas évident.