extraire un chaine (NSString) d'un tableau (NSMutableArray) de nombres
macvelotte
Membre
J'ai un beau tableau de nombres (les décimales de pi ...) sous forme de "int".
En C, avec printf, il est facile d'afficher à l'écran !
Objective-C et "Tiger" me posent des tas de problèmes.
- quel type de champ de texte utiliser ? (NSTextField, NSScrollView ... ???)
-et je n'arrive pas à obtenir la ou les chaà®nes de caractères pouvant afficher mon tableau.
Dans le même ordr d'idées, comment enregistrer le fichier correspondant (fprintf du C) ?
En C, avec printf, il est facile d'afficher à l'écran !
Objective-C et "Tiger" me posent des tas de problèmes.
- quel type de champ de texte utiliser ? (NSTextField, NSScrollView ... ???)
-et je n'arrive pas à obtenir la ou les chaà®nes de caractères pouvant afficher mon tableau.
Dans le même ordr d'idées, comment enregistrer le fichier correspondant (fprintf du C) ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ca marche aussi en Objective-C, tu as même NSLog en prime pour les sorties écran.
Des textfields devraient aller, enfin tout dépend sous quelle forme tu veux ton affichage. Je suppose que tu as des NSNumber pour représenter tes int dans ton tableau. Il faut utiliser la méthode intValue pour convertir chaque NSNumber de ton tableau en int et ensuite tu n'as plus qu'à les fournir aux textfields.
[tt]
[monTextField setIntValue:[[monArray objectAtIndex:index] intValue];
[/tt]
Pour la sauvegarde, tu as la méthode writeToFile:atomically: de NSArray.
Un textField ne convient pas : je ne peux afficher que le dernier terme du tableau.
NSTextView ne marche pas non plus ...
Genre (attention, je fais ca de tête, j'ai pas mon ibook sous la main) :
NSObjectEnumerator * lesEntiers=[tableauDEntiers objectEnumerator];
int entierCourant;
NSString * chaineResultante=[NSString stringWithString:@";"];
while (entierCourant=[lesEntiers nextObject]){
chaineResultante=[chaineResultante stringByAppendingString:[entierCourant aTransformerEnChaine (je sais pas de tête la fonction))]];
}
Et là , tu peux mettre chaineResultante dans ton NSTextField.
Tiens nous au courant !
NSLog([lesEntiers componentsJoinedByString:@";"]);
Mais cela suppose que le tableau contienne des NSNumber et pas des int.
Ben t'as qu'à les stocker en NSNumber. Ca doit pas être compliqué, un truc du style [NSNumber numberWithInt:tonInt];
Voici effectivement le code qui marche (j'ai conservé la même notation) :
Il n'y a plus qu'à améliorer la mise en page, mais ça ne posera pas de problème !
Merci !
Mais je suis très déçu par Cocoa/Objective-C : j'avais écrit en C, sous OS 9 ce programme de calcul des décimales de pi ; en 2 secondes je peux afficher 10000 décimales ; avec le même algorithme sous Cocoa, il me faudrait (calcul par extrapolation) plus de 6 minutes, soit une vitesse de calcul divisée par 120 ??? La gestion des NSMutableArray étant plus ourde que celle des Array serait-elle à l'origine de ce ralentissement qui me paraà®t indigne. >:(
Mais avant d'accuser l'Objective-C tu devrais regarder ton code de manière plus critique (ou lire toutes les réponses)... Si je me contente de regarder le code tu as retenu plus haut, il est abhérrant en terme d'optimisation:
- à chaque pas de la boucle tu crées deux objets (q et chaineresultante), alors que tu pourrais ne pas en créer (NSMutableString et appendFormat: auraient permis de l'éviter).
- les dits objets sont placés dans l'autorelease pool, ce qui connu pour etre plus gourmand en mémoire et en consommation processeur que des releases manuels.
- tu passes par un int pour créer une string alors qu'il existe une méthode qui permet d'avoir directement une string à partir d'un NSNumber.
Mais le "mieux" dans ce genre de cas est de faire ton algorithme en C et convertir le résultat final en NSString...
@Le chat noir: ne prend pas ces remarques pour toi, je suis conscient que as proposé ça en vitesse à ton boulot sans pouvoir vérifier, alors que macvelotte avait toutes les infos nécessaires
Dans la démarche, il vaut mieux faire un truc qui marche et qui algoritmiquement tient la route puis dans un second temps, optimiser. (Le top étant de pouvoir faire les 2 à la fois mais moi pas savoir faire).
Donc maintenant, à Macvelotte d'optimiser !
Et pour ça, y a du potentiel. L'algo proposé était en effet très simpliste.
L'améliorer puis, si pas suffisant, faire la routine d'aggrégat en C et convertir et afficher uniquement à la fin risque de grandement améliorer le truc et de te rendre tes anciennes performances. (NSString et NSArray, plutot lourds à manipulers).
Cocoa apporte un niveau d'abstraction qui permet d'appréhender des problèmes conceptuels avancés sans se préoccupper de pas mal de choses. Ca se paye forcément par des objets plus lourds, plus gourmands (bien que ca soit quand même pas mal optimisé !).
Mais comme Obj C permet d'encapsuler très facilement du C, ca peut être un moyen d'optimiser qques routines particulières !
En C, on utiliserait un char*, qui peut être vu à la fois sous forme d'une tableau d'octets et sous forme de chaà®ne de caractères. Là , le NSArray en Cocoa n'est-il pas trop lourd, d'office ? Enfin je ne sais pas comment tourne son algo, mais bon, ça me parait bizarre sachant qu'il l'avait fait en C avant, de monter si haut en niveaux d'abstraction et donc de désoptimiser à souhait...
Sinon tu peux aussi directement ajouter des nombres dans une mutablestring (il y a aussi une méthode qui permet d'ajouter un format à une mutablestring, ce qui dispense de la création d'une instance de nsnumber par chiffre ce qui n'est pas bon ni pour le processeur, ni pour la mémoire).
Le nouveau sujet s'appelle "Portage d'un algorithme écrit pour Carbon" (étonnamment) et se trouve dans le forum "Autres langages que objective-c".