[Résolu] Tableau ou liste de (int)
ancrou
Membre
Bonjour,
Je voudrais stocker dans un tableau, liste ou autre du genre, une collection d'adresse mémoire. Dans un type maison: UI16_
Je pensais à un NSMutableArray, mais il me demande le pointeur de mon objet !
Mais UI16_ n'est pas un objet, c'est comme un type atomique, comme int ...
Je voudrais stocker dans un tableau, liste ou autre du genre, une collection d'adresse mémoire. Dans un type maison: UI16_
Je pensais à un NSMutableArray, mais il me demande le pointeur de mon objet !
Mais UI16_ n'est pas un objet, c'est comme un type atomique, comme int ...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu peux toujours utiliser un tableau C normal (UI16_[], malloc(), free())
Sinon, tu peux encapsuler tes UI16_ dans des objets comme NSNumber ou plutôt NSValue dans ton cas.
+
Chacha
L'encapsulation serai à ma solution. Tous simplement :-/
Sinon, je stock directement les données au lieu de stocker leur adresse
J'ai fait de l'encapsulation dans un NSValue.
ça compiler, mais à l'exécution j'ai :
Mon code
Quoi de mal ?
Dire que j'ai passé du temps pour un truc de merde
Mais pourquoi dans ce cas il n'a pas eu de warning à la compil' pour dire que la classe ne répondait pas à "init" ?
A moins qu'il ne l'ait pas vu... (ou ait diminué la verbosité des warnings)
#import <Foundation/Foundation.h>
int main(int argc, char**argv){
NSAutoreleasePool * pool=[[NSAutoreleasePool alloc] init];
NSLog(@%p,[NSString init]);
NSLog(@%p,[NSString class] );
[pool release];
return 0;
}
Resultat:
% gcc pgm.m -o pgm -framework Cocoa -Wall
% pgm
2008-04-23 20:33:57.403 pgm[2358:10b] 0xa0446f00
2008-04-23 20:33:57.405 pgm[2358:10b] 0xa0446f00
%
aucun warning, même avec -Wall
Pourquoi ? Eh ben, j'en sais rien ...
Quand on fait un appel [NomClass method];, c'est transformé en quelque sorte en [NSClassFromString(@NomClass) method];
(Bon, c'est pas NSClassFromString mais un appel spécial du runtime, mais c'est l'idée...)
Or "init" est bien une méthode d'instance de NSClass jusqu'à preuve du contraire...
Ne pas oublier que quoi qu'on fasse c'est sur un objet qu'on appelle quelque-chose (de par la définition de "objc_msgSend") ; et comme "init" est une méthode de NSObject. :P
Oui, mais dans l'exemple, on fait l'appel sur la classe : [NSString init]
Second exemple :
Là on a droit à un Warning (logique) et un bug à l'exécution (logique).
#import <Foundation/Foundation.h>
@interface ClassA:NSObject
{}
-(id) instanceMethod;
@end
@implementation ClassA
-(id) instanceMethod{ NSLog(@In instance method);return self;}
@end
int main(int argc, char**argv){
NSAutoreleasePool * pool=[[NSAutoreleasePool alloc] init];
NSLog(@%p,[ClassA instanceMethod]);
NSLog(@%p,[ClassA class] );
[pool release];
return 0;
}
Le test [ClassA respondsToSelector:@selector(init)] répond YES, ce qui tente à prouver l'existence d'une méthode non documentée +(id)init sur NSObject
Et ? Comme j'ai dit au dessus, NSString est une instance de l'objet Class...
Mais non, du tout... ça prouve juste que ClassA est en elle-même une instance.
Si cette soi-disant méthode non documentée existait on la verrait avec class-dump.
test.m :
test.s :
Autre essai :
[ClassA retain];
if([ClassA respondsToSelector:@selector(retain)]) NSLog(@ClassA responds to retain method);
Ok, Ca marche
retain est une méthode de NSObject,
L'objet (de classe) ClassA est (sans doute) un NSObject
Donc ClassA répond à retain ...
Bon étant épuisé, je retourne prendre un café ...
Quant à "NSLog(NSStringFromClass([NSString superclass]));", ça retourne "NSObject" :P
Dans les autres trucs amusants :
Sinon je sais pas si c'est une bonne chose que de faire ces tests/essais avec NSString, vu que c'est une Class Cluster, donc ça peut fausser les résultats, surtout pour des tests aussi exotiques que ceux-là (à savoir du code qui n'est pas sensé être bon déjà à la base)
C'est idem sur ClassA
Autre résultat amusant : Avec une boucle pour dépasser NSUIntegerMax, il n'y a pas déallocation lors du passage du retainCount à 0 ... La boucle ci-dessous est vraiment non finie
#import <Foundation/Foundation.h>
@interface ClassA:NSObject
{}
@end
@implementation ClassA
-(void) dealloc {NSLog(@Deallocing);[super dealloc];}
@end
int main(int argc, char**argv){
NSAutoreleasePool * pool=[[NSAutoreleasePool alloc] init];
ClassA * obj=[[ClassA alloc] init];
NSUInteger r=0;
for(r=0;obj!=nil;r++) {if(r%100000000==0) printf("%u\n",r);[obj retain];}
[pool release];
return 0;
}
Sinon en relisant on disait aussi que les objets Class (comme [NSString class] qui renvoie une classe, ou plutôt un "objet de type Class, sorte de méta-objet) dérivent en fait de NSObject et c'est pourquoi elle savent répondre à init et toutes les autres méthodes de NSObject... Mais en fait je trouve pas très logique que ces classes Class dérivent de NSObject... que NSString dérive de NSObject, ok, mais que [NSString class], notre méta-objet de type Class, dérive aussi de NSObject, c'est moins logique je trouve... Enfin y'a de quoi s'embrouiller là dedans