Début sous Xcode 4.2
tablier
Membre
J'ai enfin acheté Lion et chargé Xcode 4.
Donc j'essaie de comprendre ce truc!
Je fais l'analyse d'un projet passé sous Xcode 4 et j'aimerais bien qu'on m'explique pourquoi j'obtiens l'information que la valeur de l'argument n'est pas initialisé?
La macro suivante est définie dans le .pch, donc valable pour l'ensemble du projet
Donc j'essaie de comprendre ce truc!
Je fais l'analyse d'un projet passé sous Xcode 4 et j'aimerais bien qu'on m'explique pourquoi j'obtiens l'information que la valeur de l'argument n'est pas initialisé?
La macro suivante est définie dans le .pch, donc valable pour l'ensemble du projet
et dans les méthodes ou j'utilise la macro j'obtiens:
- (IBAction)a_v3upgr:(id)sender // clic sur le bouton mise à jour
{
NSString *tic8;
v3upgrd = [o_v3upgrd indexOfSelectedItem] ;
switch (modesn) {
case mFi: switch (v3upgrd) {
case asorigin: tic8 = @fsntr08 ; break ;
case xibupgrd: tic8 = @fsntr09 ; break ;
case nibcompi: tic8 = @fsntr0A ; break ;
case nibredui: tic8 = @fsntr0B ; break ;
case nibedite: tic8 = @fsntr0C ; break ; } ; break;
case mDo: switch (v3upgrd) {
case asorigin: tic8 = @dsntr08 ; break ;
case xibupgrd: tic8 = @dsntr09 ; break ;
case nibcompi: tic8 = @dsntr0A ; break ;
case nibredui: tic8 = @dsntr0B ; break ;
case nibedite: tic8 = @dsntr0C ; break ; } ; break;
case mPr: switch (v3upgrd) {
case asorigin: tic8 = @psntr08 ; break ;
case xibupgrd: tic8 = @psntr09 ; break ;
case nibcompi: tic8 = @psntr0A ; break ;
case nibredui: tic8 = @psntr0B ; break ;
case nibedite: tic8 = @psntr0C ; break ; } ; break;
} ;
[o_snTitr08 setStringValue:localiser(tic8)] ; argument in message expression is an uninitialized value
}
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu n'as pas de "default:" dans tes switch, et il se peut que " même si d'un point de vue métier tu penses que ça n'arrivera jamais mais ça le compilateur ne peux pas le deviner " tu tombes donc sur un cas d'une combinaison { [tt]modesn[/tt] / [tt]v3upgrd[/tt] } qui ne colle avec aucun de tes cas.
Dans ce cas là , tic8 ne sera alors pas initialisé (puisque tu l'as déclaré au début mais sans lui donner de valeur), d'où le warning.
NB : Je me demande si, quand tu build avec "Analyse" (analyse statique Clang) et que tu cliques ensuite sur le warning il ne t'indique pas le cas qu'il a suivi (quelles branches de tes switch, en l'occurrence aucune de celles existantes) pour t'expliquer mieux l'erreur ?
En tout cas la solution est simple : initialiser tic8 avec une valeur par défaut (même [tt]nil[/tt]) au cas où tu ne passes dans aucun de tes switch/case imbriqués.
J'ai d'autres problèmes, mais il fait que je les cerne mieux avant d'en parler.
Est-ce que je dis des bétises?
1) Les objets à la racine d'un fichier XIB ont une politique de gestion mémoire différente sous OSX et sous iOS, attention (cf le Resources Programming Guide et la partie sur la gestion mémoire du cycle de vie des objets d'un XIB)
2) Du coup j'espère que tu as une [tt]@property(retain)[/tt] sur tes Top-Level-Objects de ton XIB pour être sûr qu'il n'est pas autorelease et détruit à la fin de l'itération de la RunLoop dans laquelle le XIB a été chargé
3) Sous OSX on a souvent qu'un MainMenu.xib et on se fout un peu de la mémoire que ça prend de tout charger d'un coup. Sous iOS c'est bien différent, on fait du lazy-loading et on ne charge les XIB que lorsque c'est nécessaire (usage typique : les UIViewControllers qui ont un XIB associé qu'ils ne chargent que quand l'écran demande à être affiché). Et surtout, iOS reçoit une alerte mémoire, si la vue du ViewController n'est plus à l'écran à cet instant, le contenu du XIB est totalement déchargé, la méthode [tt]viewDidUnload[/tt] est appellée pour qu'on fasse le ménage, et le XIB est rechargé plus tard quand il y aura de nouveau de la mémoire et surtout que la vue devra être réaffichée à l'écran (mais tant qu'elle n'a pas à être réaffichée, principe de lazy-loading, on va pas s'embêter à re-désarchiver le XIB)
Bref vu que tu as posté dans la section commune je sais pas si tu codes pour iOS ou pour OSX mais ton affirmation me semble bien dangereuse quand même...
Les variables d'instance que je veux conserver sont initialisée et reçoivent systématiquement un retain. Ce sont généralement des "Mutables".
Je vais lire l'article que tu conseilles. Mais je pense que dans le cas qui m'occupe, le problème n'est pas une dés-allocation.
Nota, je suggère que l'on supprime la section commune. Dans cette section les posts sont en majorité liés à IOS. Ce qui fait que je ne sais jamais ce que je lis!!
ajoute un breakpoint sur -[NSException raise]
cela devrait te permettre de connaà®tre d'objet responsable de l'erreur.
J'ai tout faux?
Bah si, et heureusement !
c'est du charabia....
tu as une erreur, point de supposition foireuse,
mets des logs, des asserts, des breakpoints....
et puis tu passes un NSArray quand il faut un NSMutableArray et le compilo ne rale pas??????
[self iterer:[NSArray arrayWithArray:hierarh] level:0] ;
.../...
- (long)iterer:(NSMutableArray *)top level:(NSInteger)nivo
Euuuh, il n'y a pas de retour à la RunLoop dans son code, donc aucun drainage de quelque autorelease pool que ce soit...
Euh, oui exact, là c'est moi qui divague.
Ce que j'en dis moi, c'est que tout ça mérite un bon coup d'analyse statique et d'Instruments/NSZombie.
Là , je suis d'accord, il y a une erreur quelque part et/ou une méconnaissance de quelque chose à propos des variables locales! J'avais mis des BrkPt sur l'appel de iterer et sur la première ligne exécutable dans iterer. L'état des variables parait normal, je n'en ai donc rien tiré. Non, lorsque je modifie l'argument en NSArray, je corrige aussi les déclarations pour que ça corresponde. Simplement je n'ai pas explicité la chose dans mon dernier post pour ne pas gonfler le texte.
Après modifications, le programme marche sous Lion.
Je ne fais pas explicitement de retour à la runloop ni de drainage. Et je ne comprends pas pourquoi ce retour aurait lieu durant un appel de méthode. Je crée un autorelease pool pour l'ensemble du travail d'extraction, puis je le supprime avant de retourner au contrôle principale de l'application. Pour info, vous avez la totalité de l'implémentation en pièce jointe (.zip).
Ce que j'ai trouvé sous Lion: le comportement des méthodes n'est pas forcément le même que sous SnowLeopard.
10.6.8 -> Xcode 3.2.6, SDK 10.6 compilateur "LLVM GCC 4.2"
10.7.2 -> Xcode 4.2.1, SDK 10.6 compilateur "apple LLVM compiler 3.0"
deux exemples: Donc, le comportement par défaut d'une méthode peut changer entre deux versions du système, du compilateur ou de ????? ( complétez vous-même).
oui, cela arrive très souvent avec un comportement indéfini, même si en l'état ton programme fonctionne il y a un bug.
un conseil;
décompose tes lignes de code en ligne simple (une action par ligne). tu trouveras l'action qui buge et peut être la raison.
Question:
un fichier sans nom avec une extension est t'il permis?
Courage. (contourner un bug n'est pas une bonne soluce)
PS: je ne suis pas informaticien non plus. ce n'est pas une tare
En général non, et dans les cas particuliers ce changement de comportement est systématiquement documenté. Ce n'est clairement pas le cas des messages qui posent problème
Non, sauf bug du compilateur, toujours possible, surtout avec clang vu sa relative jeunesse.
(ObjTmp est un NSString et dicoItem un dictionnaire obtenu avec ibtool)
sous 10.6.8 ObjTmp = [[dicoItem objectForKey:@object-id] stringValue] ;
sous 10.7.2 ObjTmp = [dicoItem objectForKey:@object-id] ;
si j'écris:
sous 10.6.8 ObjTmp = [dicoItem objectForKey:@object-id] ;
sous 10.7.2 ObjTmp = [[dicoItem objectForKey:@object-id] stringValue] ;
J'obtiens une erreur dans les deux cas et je ne m'explique pas la chose!
Alors ma question va être simple. Quel est le type réel des objets contenus dans le dictionnaire ?
Cela me demande deux vérifications. Une sous 10.6.8 et une sous 10.7.2.
Ta question est très bonne et je suis assez étonné. ibtool 3.2.6 et ibtool 4.2.1 ne génèrent pas le même fichier .plist malgré des "man" presque identiques et de même date (aug 15 2008)!!! voici les deux extraits: Là je suis trompé par une identité apparente entre les deux ibtool. Donc désolé, j'ai dit une bétise et après vérifications, seuls les "object-id" ont changés de type de valeur dans le .plist.