Tableau C de strings global

LexxisLexxis Membre
mars 2011 modifié dans Objective-C, Swift, C, C++ #1
EDIT : cette discussion est la suite de celle-ci :
http://pommedev.mediabox.fr/optimisation-refactoring-trucs-et-astuces/optimisation-if-else-if-ou-switch/msg69344/#msg69344

Tout dépend ce que tu as à  tester... mais pour tester des entier je passerais par un switch bien avant d'arriver aux 100 if ;-) Comme dit Céroce c'est aussi une question de lisibilité du code pour maintenance.

Ensuite pour optimiser et sous certaines conditions tu peux avantageusement remplacer tout ces tests par un tableaux. Si je reprends ton exemple
<br />title = monTableauDeValeur[self._type - maValeurDeBase];<br />

Réponses

  • AliGatorAliGator Membre, Modérateur
    17:33 modifié #2
    +1 j'allais proposer un tableau C aussi.

    Par exemple moi quand j'ai disons une TableView qui a pour but d'afficher un menu (donc contenu fixe qui ne va pas changer dans l'appli, et pas dépendant de ce que rentre l'utilisateur), je fais comme ça :
    -(UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath {<br />...<br />...<br />&nbsp; static NSString* menuTitles&#91;] = { @&quot;Vin rouge&quot;, @&quot;Vin blanc&quot;, @&quot;Rosé&quot;, @&quot;Mousseux&quot;, ... , @&quot;Digestif&quot; };<br />&nbsp; cell.textLabel.text = menuTitles[ indexPath.row ];<br />...<br />}
    
    Je vais quand même pas m'embêter à  mettre des if-else ou des switch pour ça alors que ça peut tenir en 2 lignes ;)
  • muqaddarmuqaddar Administrateur
    17:33 modifié #3
    Merci à  tous les deux pour cette suggestion du tableau en C. Bonne idée en effet.

    D'ailleurs, je pense m'en servir pour ce sujet également :
    http://pommedev.mediabox.fr/optimisation-refactoring-trucs-et-astuces/traductions-bdd-ou-fichier-strings/msg69367/?topicseen#new
  • FKDEVFKDEV Membre
    17:33 modifié #4
    Avec les optimisations, il est difficile de savoir quelle est la méthode la plus rapide.
    Le mieux c'est de regarder le code généré par les deux méthodes (si tu as un peu de temps à  perdre).

    +1 pour le tableau (en static ou en global).

    Après dans un contexte embarqué, quand le code est exécuté en ROM, on préfère parfois les if/switch au tableau constant pour économiser de la RAM.
  • muqaddarmuqaddar Administrateur
    17:33 modifié #5
    Je relance cette discussion.

    Est-ce la meilleure façon de déclarer un "bête" tableau de strings ?

    static NSString *acidities&#91;] = { @&quot;kRefreshing&quot;, @&quot;kFresh&quot;, @&quot;kCrisp&quot;, @&quot;kLively&quot;, @&quot;kRacy&quot; };
    


    En fait, je veux pouvoir utiliser mon tableau dans toute mon application, et pas dans une seule classe.
    Il faudrait un tableau "global", genre un tableau que je déclare dans prefix.pch par exemple.
  • muqaddarmuqaddar Administrateur
    17:33 modifié #6
    J'ajoute que j'ai 22 tableaux de ce genre à  déclarer, tableaux que je veux utiliser dans 4 ou 5 contrôleurs différents.
  • CéroceCéroce Membre, Modérateur
    17:33 modifié #7
    Ne l'inclue pas dans prefix.pch: ce fichier est inclus dans tous les fichiers. Si tu changes une seule lettre, il faut tout recompiler. C'est long et ça ne sert à  rien !
    (Arrêtez avec prefix.pch  :'( )

    Solution classique du langage C

    StringConstants.h:

    NSString *acidities&#91;];
    


    StringConstants.m

    static NSString *acidities&#91;] = {@&quot;kRefreshing&quot;, @&quot;kFresh&quot;, @&quot;kCrisp&quot;, @&quot;kLively&quot;, @&quot;kRacy&quot; };
    


    (En espérant que je ne me trompe pas).

    Solution que je te conseille

    MyStrings.h
    + (NSArray *)acidities;
    


    MyStrings.h.m
    + (NSArray *) acidities<br />{<br />	return [NSArray arrayWithObjects:@&quot;kRefreshing&quot;, @&quot;kFresh&quot;, @&quot;kCrisp&quot;, @&quot;kLively&quot;, @&quot;kRacy&quot;, nil];		<br />}
    


    Utiliser un NSArray apporte quelques commodités non négligeables, comme pouvoir connaà®tre la taille de liste, ou itérer.
  • muqaddarmuqaddar Administrateur
    mars 2011 modifié #8
    C'est-à -dire que j'ai toujours lu que les tableaux C étaient bien plus rapides.
    Certes dans mon cas, je n'ai pas forcément besoin de vitesse (avec 10 ou 15 records...) par tableau.

    Sinon, y'a pas moyen d'avoir un seul fichier .h par exemple ?
    C'est contraignant de remplir 2 types de fichiers pour déclarer des bêtes tableaux de strings.

    Par exemple avec le tableau C, on ne peut pas mettre directement tout dans le .h ?
  • CéroceCéroce Membre, Modérateur
    17:33 modifié #9
    Oui, les tableaux C sont plus rapide, peut-être 15 ou 30 fois plus, mais ce n'est pas un NSArray qui va ralentir ton programme.

    Avant d'optimiser au niveau des instructions, il faut déjà  avoir un algorithme qui est adapté au problème. Or il est plus simple de concevoir un algorithme performant quand un utilise des abstractions de haut-niveau, c'est-à -dire, éloignées des détails d'implémentation.
  • AliGatorAliGator Membre, Modérateur
    17:33 modifié #10
    Attention avec les static dans les .h inclus dans plusieurs fichiers, j'en ai fait les frais (cf mon autre post d'il y a qques semaines)...
Connectez-vous ou Inscrivez-vous pour répondre.