Problème avec le type de base int
Greensource
Membre
Bonjour, j'ai un souci vraiment étrange.
Je vais essayer d'être le plus clair possible. J'ai fait une classe GWcoordinate avec deux attributs x et y de type int:
Le souci c'est que quand j'instancie un objet GWCoordinate avec initWithX:Y: et bien la valeur du int devient n'importe quoi! du genre 15261951 alors que j'ai passer 1 en paramètre!
Je ne comprend pas, je me disais que les type de base étais ce qu'il y a de plus simple mais là , comprend pas. Si j'avais mis une valeur négative pourquoi pas mais là non je met 1, ça ne peut-être qu'un int!
Vous y comprenez quelques choses?
Je vais essayer d'être le plus clair possible. J'ai fait une classe GWcoordinate avec deux attributs x et y de type int:
@interface GWCoordinate : NSObject {<br /> int x;<br /> int y;<br />}<br />- (id)init;<br />- (id)initWithX:(int)abs Y:(int)ord;<br />@property (readwrite) int x,y;<br />@end
Le souci c'est que quand j'instancie un objet GWCoordinate avec initWithX:Y: et bien la valeur du int devient n'importe quoi! du genre 15261951 alors que j'ai passer 1 en paramètre!
GWCoordinate *coord;<br />coord = [[GWCoordinate alloc] initWithX:i Y:1];
Je ne comprend pas, je me disais que les type de base étais ce qu'il y a de plus simple mais là , comprend pas. Si j'avais mis une valeur négative pourquoi pas mais là non je met 1, ça ne peut-être qu'un int!
Vous y comprenez quelques choses?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est visiblement le nom de ma méthode d'init qui n'étais pas bon.
Elle s'appelait: initWithX:Y:
et j'avais un attribut x et un autre y, ça venait peut-être de ça.
Merci céroce
Cela n'était surement pas la cause.
C'est sans doute le genre de bug qu'on a du mal à trouver parce qu'on n'imagine pas avoir fait un truc pareil. par exemple, je vois dans ton premier post :
coord = [[GWCoordinate alloc] initWithX:i Y:1];
si i n'est pas initialisé, ou si c'est un float, ou si ... alors il peut être mal lu
Pour ce qui est du i dont tu parles, c'était un int initialisé dans un for. Je m'étais d'ailleurs dit que celà pouvais être la cause, donc j'ai essayer avec des constantes 2 et 3 par exemple, et pareil ça ne marchais pas.
J'ai suivi ligne par ligne au débuggueur, et c'est bien au moment de passer les param qu'il y avais une erreur, transformation d'un 1 en 15261951 ??? Bizarre hein?
Je cherchais une erreur dans ton code ...
#include <stdlib.h>
int main(void) {
int x=abs;
printf("%x\n",x);
return 0;
}
Cela écrit l'adresse de la fonction abs() de stdlib.
Logiquement, il doit y avoir un warning sur cette ligne, non ?
ça prend toujours la référence du scope le plus proche.
Tu dis Non pour le Warning , parce que l'erreur je ne vois d'où elle pourrait venir autrement ?
Et puis aussi, c'est bizarre puisque j'avais aussi un paramètre "ord" et il déconnait aussi. Je vais allez voir s'il existe dans stdlib...
Non, c'est normal, les fonctions ont une adresse :
% gcc pgm.c -o pgm
pgm.c: In function ‘main':
pgm.c:4: warning: initialization makes integer from pointer without a cast # pour x=abs
% pgm
0x92a55d7e
0x92a56fe7
0x92a58f6b
92a55d7e
%
L'erreur vient bien du nom de la méthode initWithX:Y:
CIVector en a une du même nom.
Après je ne saurais pas expliquer pourquoi ça clashe avec.
Je dis non surtout pour l'erreur. Je ne vois pas pourquoi il y aurait une erreur, puisqu'il y a un "abs" dans le scope de la méthode !
On a le droit de nommer dans un scope local des variable abs, printf ou ce qu'on veut quand même
Pas de "ord" dans la stdlib... De toute manière le problème de vient pas de là ; on a tout à fait le droit d'avoir un argument qui s'appelle "abs"
Si on a activé "-Wshadow", on aura juste un warning "warning: declaration of ‘abs' shadows a global declaration"
Ce qui veut dire que si tu essaies d'utiliser la fonction "abs" justement dans ce scope, tu auras des problèmes.
Mais j'ai déjà eu ce souci de signatures de méthodes entre classes qui se télescopent ; c'est assez désagréable j'avoue
Quand on regarde le fonctionnement interne, l'Objective-C est parfois un beau fouillis quand même.
Deux classes différentes ont bien le droit d'avoir le même nom pour une méthode ...
et en plus cela m'étonnerait que la bibliothèque CoreImage ait été importée dans le projet de GreenSource.
Et l'affectation x=abs ?
Cela demande un essai
#include <stdlib.h>
int value(int printf) {
int x=printf;
printf("coucou\n");
return x;
}
int main(void) {
printf("%d\n",value(5));
return 0;
}
% gcc pgm.c -o pgm
pgm.c: In function ‘value':
pgm.c:6: error: called object ‘printf' is not a function
%
Effectivement, cela masque le nom de fonction
et sans le printf dans la fonction, cela écrit 5.
Je l'ai fait l'essai...
J'ai pris son code, même problème, puis j'ai changé le nom de la fonction :
"initTWithX:Y:" et plus de problème.
Et on a tout a fait le droit d'avoir "x=abs" quand on a un argument qui s'appelle "abs" voyons :P
Apparemment, si... Puisque "Jump to Definition" m'a amené à CIVector quand j'avais l'ancien nom (et absolument aucun warning de "shadow" à la compilation !).
Je suppose donc que toutes les signatures sont mélangées et qu'il se mélange les pinceaux quand il va la chercher.
De toute manière, pour le runtime, les méthodes ne sont absolument pas liées aux classes, d'où le problème je pense.
Un autre gros effet de bord bordélique du dynamisme de l'Objective-C.
Incompréhensible
Pas si simple en C, cela pose le problème du choix du masquage des identificateurs au moment de la compilation. :P
Ben si c'est cela il faut arrêter tout de suite de faire de l'objective-C. Parce que là c'est n'importe quoi.
A moins que ce soit un défaut de déclaration dans l'interface qui trompe le compilateur ?
D'où le warning de shadow quand on met le flag -Wshadow
J'active toujours ce warning pour éviter de faire ce genre de chose et avoir des surprises quand j'ai une variable "n" dans un scope et une autre variable "n" dans un sous-scope par exemple.
Bugs bizarres garantis
Par contre, super bizarre... dans gdb, il passe bien par ma méthode init !! (et affiche un résultat faux derrière...)
Pour un type simple, on ne voit pas l'intérêt de cet attribut
De toute manière, le coup de l'import est flagrant. Sans tout Cocoa (et donc CI), pas de soucis.
->
Mais je le répète, j'ai déjà eu ce problème une fois (pas avec "initWithX:Y:")... j'ai pas cherché plus loin à l'époque, j'ai changé le nom et vala.
Y a forcément une erreur quelque part, il ne va pas chercher la signature de CIVector pour l'appliquer à Toto qui hérite de NSObject !