NSLog

@importer

Bonjour à  tous,

Je viens de reprendre un projet et je vois partout dans le code des NSLog vides

NSLog(@"");

Dans la console ça donne quelque chose du genre

[Classe methodeAppelée:]

ce qui me parrait fort intéressant pour voir exactement quelle méthode est appelée et à  quel moment, etc.
Seulement j'ai beau mettre des NSLog vides dans mes propres projets, rien ne s'affiche dans la console et je n'ai pas trouvé l'info sur internet.

Est ce que quelqu'un pourrait me renseigner s'il vous plait?

Merci et à  bientôt.

Thibaut

Est-ce qu'il n'y aurait pas un

#define NSLog(@""); NSLog(@"[%@ %@]", [self class], [self unMethodPourRécupérerLeMessageEnvoyer]);

quelque part ?

AliGator

Ce n'est pas une fonctionnalité qui existe.
Si les [tt]NSLog(@";")[/tt] affichent ce que tu dis, c'est qu'il doit y avoir une macro #défile qqpart genre dans le pch du projet que tu as repris.

Cherche plutôt dans le code ou les réglages du projet repris car c'est pas un truc "officiel".
Moi j'utilise un TextMacro pour faire ça, j'écris "trace" et il me met un NSLog qui affiche la classe et méthode appelée, ça peut aussi se faire par macro, donc bon...

[tt]#define trace NSLog(@[%@ %@],[self class],_cmd)[/tt]

Thibaut

Ah, c'est _cmd pour récupérer la méthode. Bon à  savoir. Merci !

@importer

Salut,
merci pour vos réponses, je m'étais déconnecté pensant avoir la solution aujourd'hui.
Encore une fois, bravo Ali. Avec tes indication j'ai regardé dans le .pch et j'ai trouvé:

#	define NSLog(fmt, ...)  NSLog((@"%s:%d :" fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__)

qui me renvoie bien en console

-[classe methode:]:ligne

Faut quand même être calé pour connaà®tre ça, nan?!
En tous cas merci beaucoup à  tous les 2, en espérant que le sujet aidera plein d'autres développeur perdu sur des projets à  reprendre.

Pierre

AliGator

En effet :
- __PRETTY_FUNCTION__ est une macro prédéfinie qui contient le nom de la méthode courante, j'étais pas sûr que ce soit une macro utilisée par le gcc4 de OSX (ça fait un bail que je l'ai pas vue elle :P)
- "_cmd" est une variable interne propre à  Objective-C. En fait, quand tu écris une méthode [tt]-(void)toto:(int)x[/tt], le compilateur va le traduire lors de la compilation par [tt]objc_msgSend(self,@selector(toto,x)[/tt]. Ces paramètres sont cachés pour toi, mais c'est ce qui permet à  ObjC d'avoir la variable "self" qu'on utilise souvent et représentant l'objet courant... et donc "_cmd" aussi, qui est il est vrai bien moins connu.


Après perso une macro comme celle que tu cites @importer moi j'en utilise tout le temps dans mes codes (sauf que j'appelle pas ça NSLog, mais PPLog ou AliLog ou autre pour la distinguer, j'aime pas qd ça peut prêter à  confusion avec l'existant justement la preuve vu ta question), ça permet d'avoir des traces super pratiques pour déboguer.

dans 1265620366:

Faut quand même être calé pour connaà®tre ça, nan?!

Bah c'est ça l'expérience, qu'est ce que tu crois :P Faut bien qu'on ait un avantage à  pas être jeune dans le métier

@importer

Salut Ali,

Justement en parlant de debugger (peut-être devrais-je lancer un nouveau thread?!), dans la console j'ai un message:

objc[2830]: FREED(id): message size sent to freed object=0x4959710

Le debugger est lancé mais rien ne s'y affiche. Pourtant j'ai réglé pour que le debugger et la console se lancent à  la compilation en tous temps. Je capte pas.
est ce que tu pourrais m'indiquer le process stp pour que quand ça plante je puisse trouver le fameux object=0x4959710 qui fait out planter? parce que j'avoue que sans ça je ne suis pas prêt de le trouver :$

muqaddar

J'ai parfois ce message.
Il signifie que tu appelles une méthode sur un objet déjà  releasé.

C'est vrai que celui-ci j'ai parfois du mal à  le débuguer, mais je m'en sors en parcourant mon code avec le débugguer ligne à  ligne.

@importer

Salut Muqadar,

Anéfé, j'en ai fait exprès de mettre un BP un peu n'importe où (c'est pas mmon projet, je le connais pas) et j'ai fait Continue pour trouver d'où ça venait. Merci pour ton aide. 

edit: y aurait il un moyen pour que le debugger affiche d'où vient le problème sans être obligé de mettre un BP? Merci

AliGator

Tu peux mettre des breakpoint sur des lignes particulières de ton code (le plus courant et le plus connu), mais aussi sur des appels de fonctions (tu mets un breakpoint nommé, en spécifiant le nom du @selector de la méthode qui t'intéresse, et d'où qu'elle soit appellée ça va s'arrêter quand elle est appellée), mais aussi des breakpoints pour t'indiquer quand la valeur à  une adresse mémoire particulière change de valeur.

D'ailleurs au sujet des breakpoints, tu as aussi la possibilité de ne pas faire qu'ils s'arrêtent, mais qu'ils fassent autre chose (afficher un message dans la console -- ce qui permet de faire un peu l'équivalent d'un NSLog que tu rajouterais à  la main, sauf que t'as pas à  éditer ton code tu peux le faire en live quand est en plein débug sans stoper et devoir recompiler ton appli pour ça -- ou jouer un son, etc) ce qui peut être très pratique quand ce sont des soucis temps réel que tu débug (car arrêter l'exécution du programme au BP peut fausser le résultat dans ce cas précis où le timing joue), ou quand tu veux débuguer un endroit où il y a beaucoup de fois où ça peut s'arrêter et qu'un son pour t'avertir juste que telle méthode est appellée plutôt que s'arrêter 50x dedans est plus efficace.

JegnuX

Bon à  savoir tout ça, bien pratique. Merci !

@importer

Bien d'accord là  dessus, très pratique. Merci pour ces astuces 

Lastiko

merci je viens de tester _Pretty_Function_ et je trouve ca bien pratique

AliGator

D'ailleurs au fait au dessus j'ai utilisé _cmd directement dans le NSLog, alors que c'est une variable interne de type SEL (autrement dit un @selector), donc pour l'afficher c'est plutôt [tt]NSStringFromSelector(_cmd)[/tt] si on veut un affichage similaire à  __PRETTY_FUNCTION__

Paisible.fr

A propos du NSLog on notera l'article qu'Apple y consacre dans sa Knowledge Database :

Technical Q&A QA1669 : Improved logging in Objective C