Salut,
 
Est-ce qu'il y a un moyen de passer en argument d'une fonction B la fonction A (ou son nom) qui l'appelle ? J'ai un programme qui affiche (enfin qui peut potentiellement afficher) plein de warnings et je voudrais les regrouper dans une fonction warn, faire un truc du genre :

 
C'est complètement inutile, je sais, mais ça me semble plus propre parce que :
1- Tous les avertissements sont au même endroit, pratique si je veux changer leur format (ou leur langue, bien que ça n'arrivera pas)    
2- Ça m'évite d'avoir plein de cout tout moches en plein milieu du code...  
3- Si c'est possible j'apprend quelque chose, donc ça me fait progresser un peu
 
Alors ? Verdict ?
 
Merci.
 
PS : Je sais pas trop comment formuler mon problème dans google, alors soyez indulgents...

Il te faut des pointeur sur des fonctions pour faire ce genre de trucs :
 
http://c.developpez.com/megacours/x2012.html
http://www.ann.jussieu.fr/courscpp [...] 05-H0.html
http://c.developpez.com/faq/c/?pag [...] u_pointeur
 
entres autres

Oui. Je m'attendais plus à un truc générique qui aurait été équivalent à "this", mais c'est vrai que je pourrais tout simplement donner en argument de Warn() un pointeur de fonction adapté à chaque fois. Mes fonctions ayant un type différent, je serais obligé de les transtyper mais c'est pas bien grave puisque seul le nom m'intéresse, et ensuite (le déclic à eu lieu en parcourant un de tes liens (bien qu'il n'en parle absolument pas), donc merci ) faire un mapping entre la fonction et le warning.
 
Malheureusement, je n'y avais pas pensé plus tôt mais mes fonctions peuvent contenir plusieurs avertissements... Évidemment je peux mettre un deuxième argument à Warn(), mais au lieu d'améliorer la lisibilité (mon but initial), je pense que je m'engage dans un truc qui va rendre mon code enore bien plus illisible qu'il ne l'est déjà.
 
J'abandonne donc l'idée pour l'instant.
 
Merci quand même.

Dans ce cas là, plutôt que de t'embêter avec des pointeurs de fonctions transtypés, pourquoi ne pas passer à ta fonction tout simplement un identifiant (par exemple de type int) qui caractérise l'erreur

Je sais pas, ça me semble trop confus, au moins dans le cas des entiers : il faudrait à chaque fois aller voir la liste des erreurs pour voir le message, faire attention à ce que l'entier ne soit pas déjà pris, ne pas se tromper d'entier... À la rigueur une chaine de caractères, c'est vrai que ça serait aussi (et même plus) simple que des pointeurs de fonction adaptés à chaque fonction (enfin je me comprends...), mais je trouve pas ça très élégant... C'est pour ça qu'à la base j'attendais un truc équivalent à "this" pour les fonctions, beaucoup plus générique.

Je vais y réfléchir.  

PS : Un autre argument imparable est que j'ai un esprit tordu...

Avec une batterie de define tu peux faire un truc tres clair rien qu'en apssant des int franceso a raison.

Les "#define", c'est le Mal.

Utiliser des int serait envisageable dans la mesure où plusieurs warnings seraient identiques. En l'ocurrence, le même warning n'apparait jamais deux fois, mais il peut y avoir plusieurs warnings différents par fonction. Je viens de compter :

Je pensais pas en avoir autant, mais tu vois, les int ça sera vite le bordel...

pfff les #define c'est le mal que si tu en fait n'imp'.
 
un chtit
 
#define WARNING_JASAISPASQUOI 5
 
puis un warn(WARNING_JASAISPASQUOI) c'est quand meme bien mieux qu'un warn(5) . . .

Autant utiliser un static const alors, non ?

Mais bon, c'est pas le problème, je veux pas définir 80 variables juste pour ça. C'est aussi moche que mon "cout<<WARNING_JASAISPASQUOI<<endl;" (devrais p'têt mettre un cerr d'ailleurs), donc ça ne présente pas grand intérêt.

Ce sera un équivalent de this ou rien. Donc rien.

(À moins que je ne change brusquement d'avis, genre en pleine nuit après un vilain cauchemard où je me ferais agresser par des define en colère...)

static const cree une varaible en memoire, je ne vois pas ce que ca apporte dans ce cas . . .
 
et puis le cout tu est censé le faire dans la fonction warn non ? avec un switch/case, ya moyen de faire quelque chose.
 
Globalement, quelque soit le systeme que tu choisis de mettre en place, tu devra te taper les 76 execptions.

Ben un static const en global a le même effet qu'un define, non ? (Je sais, les variables globales c'est aussi le Mal...)
 
Sinon, c'est bon, j'ai trouvé ce que je cherche : la macro __func__ retourne le nom de la fonction :

donne :

 
 
Maintenant pour l'implémentation de la fonction Warn() il va falloir que je réfléchisse encore un peu (dans quelle classe la mettre, sachant qu'il y a de l'héritage derrière, le coup des plusieurs warnings pour une même fonction, etc.), mais c'est une autre histoire.
 
Merci, @plouche.

Bon bah tant mieux si ca marche comme ca. Je connaissait pas __func__
 
Par contre, rien a voir entre uen variable globale et un define. Le define modifie ton code source avant compilation, alors que la variable globale se trimbale en memoire comme n'importe quelle variable.

À noter que __func__ est un standard du C99, pour des compilateurs ne le respectant pas ça peut être __FUNCTION__, ou autre chose, ou rien...
 
Pour l'implémentation (je le dis même si ça n'intéresse personne, à des fins d'archivage... ), je pense que le mieux est de définir Warn() dans la classe mère, ainsi qu'une méthode virtuelle qui définira tous les warnings dans une map, et qui sera redéfinie dans les classes filles pour y ajouter les warnings spécifiques à ces classes filles.
 

Merci pour la clarification.
 
Mais au final le comportement du programme est le même, donc quel est l'avantage de l'un par rapport à l'autre ? On entend partout que les deux sont à proscrire...
 
 
 

les macros cai surpuissant

le #define peut avoir des effets pervers :
 
si par exemple, je fais :

 
Il faut donc faire attention dans la definition de ses marco a bien mettre des parentheses partout car l'oublis d'un parenthese peut etre fatal. de facon generale, sauf dans des cas tres particulier d'optimisation de code, il ne faut donc pas utiliser les macro dans ce but.
 
Par contre les macros sont tres utile pour le nomage de constantes golabales. Si par exemple tu veux cree des erreur numerotées dans ton programme, il peut etre tres fastidieux de se souvenir de quel numero est associé a quelle erreur. les #define sont la pour aider dans ce cas et doivent etre utilisées.
 
Une variable globale constante, je vois pas bien l'utilité, a part si elle est externe et destinée a etre modifiée plus tard, ou bien si on veux s'en servir comme "signature" dans le code compilé, sans vraiment l'utiliser dans le programme (un chargement de registre avec un valeur en dur est jusqu'a 60 fois plus rapide qu'un chargement depuis la memoire, sans compter une eventuelle rupture de pipeline si le bus memoir eest pas disponible, bref a eviter).
 
Une variable globale (non constante) est a eviter car elle est plus souvent source de bug que de solutions, et il existe presque toujours une autre solution au moins aussi efficace. Au pire, et comme on est en C++, on cree un namespace et on faitr des variable globale au namespace. mais bon, c'est pas classe, et c'est surtout plus de problemes que de solutions.

Y'a les enums aussi qui sont trés bien pour définir un set d'erreurs possibles (pour cet exemple précis, parce que c'est trés bien pour définir n'importe quel set de "valeurs" ).

 
 
Je dirais jamais, mais je peux me tromper.
 

 
 
Edit : d'accord aussi avec les enums de IrmatDen, même mieux que mon bidule là-dessous.