Switch et NSString
Greensource
Membre
Je remarque que le switch n'apprécie pas les pointeur en tant que "case value", ce que je peut comprendre 
Mais alors comment faire un switch sur différente valeur de NSString? Vais-je être réduit a un if else if else if else sans fin?
Mais alors comment faire un switch sur différente valeur de NSString? Vais-je être réduit a un if else if else if else sans fin?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Heuu pas à ma connaissance du moins. Mais ça dépend du contexte, et quels sont ces NSString. Quand c'est des NSMenuItem par exemple je m'arrange souvent pour jouer avec les tags.
Dans ce cas je te conseille de mettre des @selector dans ton plist à la place
2 - Ca risque pas de faire beaucoup de méthode à implémenter ça?
Je crois que je vais rester sur le if else du coup.
mias il faut vérifier (mes cours de C sont loin) si le case accepte des fonctions à la place des litéraux.
Sinon, reste les séries de if non-imbriqués simulant le switch :
Mais pourquoi le switch ne s'adapte pas au monde de l'objet, c'est étrange quand même? Avec le isEqual de NSObject ya moyen non?
Non, les case n'acceptent que des entiers.
Parce qu'ObjC n'est pas un langage objet pur. Essaie de programmer un peu en Python, par exemple, et un tas d'aspects d'ObjC te paraà®tront fort rétrogrades.
ObjC est un compromis entre la vitesse d'exécution et la facilité d'écriture. C'est un langage bien adapté aux performances des machines actuelles, mais ce n'est pas un langage d'avenir.
La valeur testée doit être de type intégral et les cases des constantes.
Il fut un temps où ça devait être uniquement du int.
Kernighan & Ritchie :
Pour comparer des strings, il vaut mieux utiliser isEqualToString
1) Pour comparer 2 entiers grosso modo, on charge la 1ère valeur dans un registre, la seconde valeur dans un second régistre, on fait la différence et on choisit une branche ou l'autre (on fait un saut dans le programme ou pas) si ladite différence est zéro (genre instruction JNZ, Jump If Not Zero)
2) Du coup pour comparer une valeur particulière à différentes constantes, ce qui est le cas du switch/case, on charge la valeur de notre variable dans un registre, et ensuite on a plus qu'à enchaà®ner {chargement de la constante, et test si la différence vaut zéro ou non} pour chaque constante avec laquelle on veut comparer.
Pour moi le switch est le reflet du fait que si on compare nos constantes toujours à la même variable, autant ne charger cette variable dans le registre qu'une seule fois. Historiquement du moins ça me semblerait logique que ça hérite de ça.
Maintenant, entre toutes les optimisations des compilateurs et améliorations des CPU et architectures matérielles, ce n'est plus forcément d'actualité. Mais ça justifie l'existence du switch... et surtout la raison pour laquelle ça ne marche que sur des entiers.
Si tu veux comparer des objets en utilisant des fonctions (genre isEqualToString), le process utilisé n'implique plus du tout les mêmes mécanismes au final sous le capot (et donc côté code assembleur) et n'offre plus le même fonctionnement que celui décrit (donc l'avantage de chargement unique de la valeur dans un des registres)... donc le switch n'est plus adapté du tout.
Sinon pour la solution d'utiliser le hash, c'est pas idiot... Sauf que le hash n'est pas forcément unique, seulement pseudo-unique : le principe d'un hash c'est en général que 2 objets identiques auront le même hash, mais que 2 objets qui ont le même hash ont juste de fortes chances du coup d'être identiques, mais ne le sont pas non plus forcément à 100%. Ca permet d'accélérer les comparaisons grace à la probabilité plus forte que les objets soient identiques avec une comparaison rapide (car mettant en oeuvre des int et non des objets), mais une fois qu'on a vu que les hash étaient identiques, il faut qd mm vérifier que les objets le sont aussi.