Xcode 4 me donne des erreurs (assez inutiles) sur "Sélecteur non implémenté" XXX '"lorsque j'essaie d'utiliser @Selector (xxx) avec n'importe quelle méthode non définie dans le même fichier source. L'erreur disparaît (au moins pour la construction du projet) si je définis l'avertissement de compilateur LLVM, "Types de définition multiples pour le sélecteur" sur "Non". (Ceci est la valeur par défaut iOS, mais pour mon projet, il avait été activé.) Cependant, même avec cela éteint, l'erreur apparaît toujours dans l'éditeur si "Activer les problèmes en direct" est cochée dans la boîte de dialogue Paramètres de version.
Alors maintenant, j'ai désactivé des problèmes en direct afin de ne pas être distrait, ce qui est un peu laissé tomber. Ma question est la suivante: Y a-t-il une façon de vous débarrasser de l'erreur par, peut-être, préciser quelle définition d'un sélecteur que je veux utiliser? Ou peut-il même compter, c'est-à-dire toutes les définitions d'une méthode partagent le même sélecteur dans l'objectif-C? Est-ce un bogue de compilateur, ou peut-être un cadre faux que je devrais juste partir? (et si ce dernier, pourquoi est-il sur la fonctionnalité de construction en direct dans le nouvel éditeur?) Strike> P>
Voici le code, juste pour être clair: P>
error: unimplemented selector 'translationInView:' [-Wselector,2]
if ([recognizer respondsToSelector:@selector(translationInView:)]) {
^
4 Réponses :
Les sélecteurs n'ont aucun lien avec les définitions. À son niveau de base, il s'agit vraiment d'une valeur unique qui identifie le nom d'une méthode. Les méthodes suivantes ont tous exactement le même sélecteur: @interface NSObject (SelectorStuff)
- (CGPoint)translationInView:(UIView *)view;
@end
J'avais fait quelque chose de similaire à ce que vous suggérez avec la catégorie, mais j'ai copié et collé votre code exact dans le fichier et j'ai toujours l'erreur. J'ai ajouté le texte de message d'erreur exacte (à partir de la construction de la ligne de commande) à la question ci-dessus, car clarifiez.
@Big_M c'est un avertissement curieux compte tenu de la nature du drapeau qui l'a créé. Je dirai que -wselector n'est pas une bonne idée d'activer la plupart des projets Obj-C. Il a tendance à provoquer des erreurs inutiles.
Inutile et incompréhensible! :-( Mais merci pour votre aide, @kevin. Je suppose que je laisserai cet avertissement pour l'instant. (Et j'ai compris le problème avec des problèmes en direct dans l'éditeur - voir mon commentaire à la question ci-dessus.)
de la langue de programmation de l'objectif-C Guide :
Les sélecteurs compilés sont de type SEL. Toutes les méthodes portant le même nom ont le même sélecteur.
...
Pour l'efficacité, les noms d'ASCII complètes sont non utilisé comme sélecteurs de méthodes dans Code compilé. Au lieu de cela, le compilateur écrit chaque nom de méthode dans une table, puis paires le nom avec un unique identifiant qui représente la méthode à l'exécution. Le système d'exécution fait Bien sûr, chaque identifiant est unique: pas deux Les sélecteurs sont les mêmes, et tous les méthodes avec le même nom ont le même sélecteur.
Donc, aussi loin que les sélecteurs vont, la définition n'a pas d'importance ... Seul le nom de la méthode.
Si vous utilisez le front-end gcc, vous devez définir ce drapeau pour obtenir ces avertissements: Notez que ce drapeau n'est pas défini par défaut, de sorte que cela pourrait D'une manière ou d'une autre devons avoir été ajoutée à votre configuration de construction afin que vous voyiez maintenant l'avertissement.
Je crois que c'est en fait le drapeau -wselector (comme indiqué dans le message d'erreur) qui est la source. J'ai essayé de supprimer celui que vous avez mentionné et que cela n'avait eu aucun effet, mais supprimer -wselector le rendait parti. L'erreur (malgré le message d'erreur) n'est pas si le sélecteur est non déclaré, mais apparemment qu'il est multiplié, même si cela ne devrait pas vraiment faire la différence. Franchement, je trouve cela assez déroutant et je me demande toujours s'il s'agissait d'un bogue LLVM / Clang. Quand j'ai du temps, je vais expérimenter avec la GCC.
HM, pourrait bien être un problème de clang. Je n'ai pas été capable de le reproduire avec le front de la GCC.
Confirmé. Je n'ai pas l'erreur avec GCC ou GCC / LLVM. Je fais cependant d'autres erreurs. ::soupir::
Personnellement, je considère que ceci est un bogue dans le compilateur, car l'erreur apparaît même lorsque le sélecteur est déclaré dans une catégorie différente, auquel cas le compilateur devrait supposer en toute sécurité qu'il n'est pas implémenté dans cette < / em> fichier source. Le compilateur doit signaler cela comme une question possible à confirmer à la liaison-heure et uniquement s'il n'y a vraiment pas de mise en œuvre une fois que tous les objets / bibliothèques sont liés, il s'agit de cet avertissement.
J'ai compris que l'éditeur utilise les paramètres de construction en vigueur lorsque le projet a été ouvert, les modifications ne prennent pas effet tant que le projet n'est pas fermé et rouvert. C'est pourquoi l'erreur est maintenue dans l'éditeur, même après avoir changé l'avertissement. Quelque chose à conscience de si vous utilisez Xcode 4.