assert(??)
tablier
Membre
Je suis tombé sur la macro assert, et je ne comprends pas vraiment ce que ça fait.
J'ai trouvé la définition dans assert.h, mais ça fait appel à la macro "__builtin_expect" et aux deux routines "__assert_rtn" et "__eprintf".
Quelle est l'explication?
J'ai trouvé la définition dans assert.h, mais ça fait appel à la macro "__builtin_expect" et aux deux routines "__assert_rtn" et "__eprintf".
Quelle est l'explication?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Elle permet de vérifier, en général uniquement en mode debug, si une condition est vraie, et de lever une exception si ce n'est pas le cas.
C'est pratique pour mettre des gardes-fous en mode debug pour s'assurer que tu n'as pas d'incohérences dans ton code.
Exemple : Ici avec assert (enfin NSAssert, qui est une variante définie par la macro NSAssert de CoreFoundation) en mode debug tu t'assures que l'index i que tu as récupéré ne va pas sortir des bornes de ton tableau et que tu ne risques pas de demander un objet à une position qui n'existe pas dans le tableau. Si c'est le cas ton programme remontera une exception en mode debug avec le message indiqué en paramètre, ce qui va t'aider à déboguer. En mode Release, en général la même macro est définie à .... rien, ce qui fait comme si la ligne avec NSAssert n'était même pas présente.
En fait en général on utilise NSAssert & consoeurs (les assertions en général) pour s'assurer qu'une valeur respecte bien une propriété qu'elle est sensée respecter, soit par construction, soit par convention d'après l'architecture de ton code, et donc une valeurs que normalement on n'a même pas besoin de vérifier parce que si tout marche comme prévu y'a pas de raison que l'assertion soit fausse.
Par exemple dans mon code plus haut, il se peut que tu saches que tab a théoriquement été initialisé à un NSArray contenant 10 valeurs, et que par construction machinTruc est une NSString qui a été créée en prenant le premier caractère d'une chaà®ne disons. Donc à ce stade tu te dis "machinTruc contient forcément soit un caractère entre 0 et 9, soit un caractère qui n'est pas un chiffre et donc pour lequel intValue retournera 0, dans tous les cas i ne pourra avoir qu'une valeur entre 0 et 9" conclusion théoriquement c'est même pas la peine de vérifier et d'ajouter cette vérification avec un "if" dans ton code, test qui ne servirait, du moins théoriquement, à rien.
Mais tu te dis que bon si un petit malin venait à modifier le code et l'initialisation de ton tableau "tab" un jour et qu'il oubliait du coup cette particularité de ton code cité ici, il ne faudrait pas que ça casse tout... donc tu mets quand même un "assert". Ou si jamais, tu ne vois pas pourquoi mais sait-on jamais tu aurais pu oublier un cas, si jamais i pouvait avoir une valeur <0 ou >9 malgré le raisonnement qu'on vient de tenir...
Bref voilà à quoi servent les assertions, à vérifier un truc juste en mode debug, un truc qui est sensé être vrai par construction de ton appli ou quoi, donc que théoriquement tu n'as pas à tester avec un "if", mais tu mets une assertion quand même pour vérifier quand tu es en mode debug que y'a pas un truc qui part en vrille et qui te casse tout et ne respecte pas la théorie
D'ailleurs il faudra que quelqu'un d'ici nous ponde un tuto sur les test-case unit-test parce que je trouve ça assez flou personnellement.
On devrait te surnommer 'Spotlight' tiens... J'avais trouvé qu'un vieux tuto made in Apple sous 10.3-10.4
(Je t'en prie, ne réponds pas par "Bha il suffit de chercher "test-case" dans la doc Apple et...." :P )