est la fonction de surcharge possible dans l'objectif c?
Eh bien, la plupart des programmeurs disent non,
de
Mais cela semble possible,
par exemple:
-(int)AddMethod:(int)X :(int)Y
{
return X + Y;
}
-(int)AddMethod:(int)X
{
return X;
}
7 Réponses :
Non, ce n'est pas, principalement parce que l'objectif-c n'utilise pas de fonctions, il utilise des méthodes.
La surcharge de la méthode, d'autre part, est possible. Sorte de. Considérez si vous voulez, si vous voulez, une classe avec une méthode prenait un argument sur la forme d'un tandis que la méthode elle-même ne contourne pas la méthode appropriée avec une entrée donnée; On pourrait toujours dire que Nstring * ou un const char * :: Dothing: a été surchargé, au moins en ce sens que les deux méthodes prenant un paramètre différent pour atteindre la même fonctionnalité.
Les réponses doivent avoir au moins 15 caractères; Donc, j'ai un peu tendu le mien. ;)
L'exemple n'est même pas Sorte de surcharge , ce sont simplement deux méthodes différentes pour lesquelles la nommée implique une relation sémantique. C'est juste l'alternative couramment utilisée en l'absence de surcharge.
@Georg: Ce qui, selon l'essence, est la manière dont la surcharge est implémentée, par exemple, C ++: les méthodes surchargées ont le même nom dans le code, mais leurs noms réels et mutilés sont différents, et le plus approprié est choisi lors de la compilation. Le même principe est au travail ici, la seule différence étant que le programmeur choisit le nom «mutilé» correct, pas le compilateur.
@Williham Totland: Nom Mangling est juste un détail de mise en œuvre. Il n'y a rien à dire qu'un compilateur / lieur C ++ doit utiliser Name Mangling.
Outre Name Mangling étant un détail de mise en œuvre, la surcharge est une fonctionnalité linguistique avec tous les avantages groupés (par exemple, une utilisation C ++ d'un seul nom de fonction dans un contexte générique).
@Georg Fritzsche: Certaines personnes diraient que ce n'est pas un avantage :)
La surcharge de la méthode n'est pas possible dans l'objectif-c. Toutefois, votre exemple fonctionnera en fait car vous avez créé deux méthodes différents avec différents sélecteurs: -AndMethod :: et addmethod: . Il y a un point de point pour chaque paramètre entrelacé. Il est normal de mettre du texte aussi par exemple. -AndMethodx: Y: Mais vous n'êtes pas obligé.
Vous n'avez pas avoir pour étiqueter le deuxième paramètre, mais vraiment ... vous devez. Il n'y a aucune raison de rendre votre code intentionnellement obtus.
@kubi: Complètement d'accord. Il est le même genre de "ne pas avoir à" comme dans "Vous n'avez pas à utiliser des lettres de noms de variable C, vous pouvez simplement utiliser des chaînes de traits de soulignement".
je suis confus ... Je pensais que c'était compté comme surcharge de la méthode (nombre différent d'arguments ou de types) édition: OK, il semble que seuls les types ne comptent que surcharger pour vous les gars ... dans tant d'exemples en ligne, je vois que même différents La signature compte comme "surcharge". Soupir...
Techniquement, la surcharge de la méthode n'est pas possible dans l'objectif-c. En pratique, vous pouvez généralement obtenir les mêmes résultats, également dans les cas où vous ne pourriez pas en C ++. Dans l'objectif-c, les noms de méthodes comprennent un côlon devant chaque argument et les colons font partie du nom de la méthode, ce qui signifie que votre exemple utilise des noms de méthodes différents. En pratique, cela devient une sorte de fonctionnalité de paramètres pseudo-nommée et vous pouvez obtenir une surcharge de la méthode pseudo par action plutôt que par type d'argument. Dans la plupart des cas, cela sera effectivement plus utile, mais ce n'est pas une surcharge de la méthode dans le sens strict, car les noms de méthodes sont différents.
Exemple: P>
-(void)encodeFloat:(float)realv forKey:(NSString *)key -(void)encodeInt32:(int32_t)intv forKey:(NSString *)key
Catégories Fournir un autre moyen d'émuler surcharger la surcharge de la méthode de style C dans l'objectif C. Par exemple, considérez les déclarations d'interface suivantes: Les différents types de paramètres sont résolus par les catégories. < / p>
Vous pouvez commencer par une méthode générique que des itinéraires basés sur le type de l'objet que vous passez.
- (void)doSomethingWithData:(NSData *)data; - (void)doSomethingWithImage:(UIImage *)image;
Notez que si vous avez besoin / souhaitez surcharger des fonctions lors de la combinaison de l'objectif-C avec C ++, il est possible. Je ne le mentionne que parce que dans Xcode, vous devez modifier votre fichier .m vers un fichier .mm pour le traiter de cette façon, qui m'a trébuché pendant quelques minutes.
exemple d'en-tête: P>
void addMethod(NSInteger a); void addMethod(NSInteger a, NSInteger b);
Vous pouvez surcharger C Fonctions avec de nouveaux compilateurs - Syntaxe est un peu maladroit, cependant (rien de plus rapide #define ne peut pas corriger), mais cela fonctionne bien.
J'ai lu plusieurs fois les programmeurs disant que la surcharge de fonction n'est pas possible dans l'objectif C.
Ceci ne surcharge pas, vos méthodes ont des sélecteurs différents (= noms). One est
addmethod: et l'autre estaddMethod ::