Et la plupart des avantages que prodigue l'ObjC sont balancés aussi par les avantages du C++. Par exemple, la notion de templates (cf typiquement la STL) me manque parfois cruellement en ObjC, du genre, on peut faire des NSArray d'objets de types différents, et il n'y a aucune indication dans le type de l'objet (NSArray) pour savoir le contenu du tableau (c'est un tableau de quoi ??). Donc c'est du coup un peu trop permissif, et dans l'absolu si on veut être rigoureux il faudrait ensuite vérifier le type de l'objet (ou tester avec respondsToSelector: ) extrait du tableau avant de l'utiliser... alors qu'en C++ cette vérification n'est pas nécessaire, étant inhérente par le type de l'objet.
Pour commencer, en général on connaà®t toujours le type des objets que l'on met dans un NSArray, ensuite, on peut très bien faire un simple code de wrapping pour contrôler le type d'un objet avant de l'ajouté à un NSMutableArray. Et pour finir, même en étant rigoureux, l'utilisation de la méthode "respondsToSelector:" (qui soit dit en passant n'est pas spécifique à NSObject) n'est pas nécessaire et peut même aussi induire en erreur, car bien que cette méthode retourne NO, l'objet peut très bien répondre à la méthode via, notamment, d'objets délégués, c'est tout le principe de la redirection qui n'est pas non plus réservé à NSObject, bien au contraire.
dans 1189361379:
Pour résumer, en C++ on peut déclarer une variable de type "tableau d'objets A" genre un tableau de personnes, alors qu'en Cocoa on peut faire des NSArray mais ces derniers pourront contenir tout et n'importe quoi et on n'a aucune garantie de leur contenu. Donc pour bien faire on devrait tester le type. Et ObjC sans Cocoa n'en parlons pas, il n'y a rien de spécial pour gérer les tableaux à part les malloc (nécessitant l'évaluation de la taille d'un objet en mémoire pour créer un tableau desdits objets) bien moins intuitifs que les "new" (genre [tt]Voiture* tabVoitures = new Voiture[nbVoit];[/tt] pour créer un tableau de 1à voitures au lieu de [tt]Voiture* tabVoitures = (Voiture*)malloc( nbVoit * sizeof(Voiture) );[/tt])
Ah parce qu'en Objective-C on ne peut pas déclarer de tableau d'objets peut-être ? Il faudrait alors me dire comment vous envisagez le stockage des éléments dans un NSArray... Un objet étant toujours alloué dynamiquement en Objective-C il suffit de déclarer un tableau de pointeur sur objet, si tu veux le type de base : id *tableauDObjet, si tu veux te faire un tableau de NSObject : NSObject **tableaudeNSObject. Notez par ailleurs que NSObject et id sont deux choses totalement différentes, car bien qu'il est conseillé de faire hériter ses objets directement, ou indirectement, de NSObject, ce n'est pas obligatoire, il existe d'ailleurs plusieurs classes racines dans Cocoa (NSObject et NSProxy...)
dans 1189361379:
C'est bien ce qu'il me semblait, je veux dire les gens qui n'ont fait que peu de C++ ne connaissent pas forcément les trucs et astuces parfois utiles et concepts avancés du C++ (tous les concepts de POO qui ne sont pas tous présents en ObjC, l'aspect pointeurs de fonctions pouvant remplacer le type (SEL) de Cocoa, l'aspect templates, la possibilité pour une classe de dériver de plusieurs classes mères, y compris des classes abstraites ou des interfaces, etc)
Les électeurs, type SEL, ne sont pas des pointeurs de méthode ! Les sélecteurs sont des identifiants de méthodes, ce n'est pas pareil. Un pointeur de méthode en Objective-C c'est le type IMP, définit comme ça : typedef id (*IMP)(id, SEL, ...); Il est utile en général pour faire plusieurs appels à la même méthode sur le même objet (ou sur un objet qui répond exactement à la même méthode) genre dans une boucle par exemple, pour éviter de passer par le système de vérification à chaque tour. L'héritage multiple du C++ peut-être facilement reproduit par des objets qu'on pourrait qualifier de "délégué", on peut par exemple utiliser un objet, dont on connaà®t le type, dans un autre pour lui envoyer plusieurs méthodes, et bien sûr inutiles de redéfinir toutes ses méthodes il suffit de faire de la redirection.
dans 1189411527:
Tu sais que le runtime de l'Objective-C qui autorise ça (car il gère les méthodes par "sélécteurs" ; c'est de l'indirection) le rend particulièrement lent par rapport aux appels C / C++ ? Et que pour faire un Wrapper sur un truc graphique qui demande pas mal de puissance, ça va être un peu la loose.
Je conteste l'utilisation du mot "particulièrement" devant "lent", en effet, le fait de devoir rechercher quelle méthode utiliser à chaque fois ralentit l'envoie des messages, cependant, en plus du contournement que j'ai cité plus haut, le runtime met les méthodes qu'il a déjà exécuté dans une cache qui permet d'accélérer la redirection, ce qui fait qu'un envoie de message devient pratiquement aussi rapide qu'un appel à une fonction C. Et après, un certains temps d'utilisation d'une application objective-c la majorité des messages sont cachés et permettent une utilisation optimale.
Réponses
Pour commencer, en général on connaà®t toujours le type des objets que l'on met dans un NSArray, ensuite, on peut très bien faire un simple code de wrapping pour contrôler le type d'un objet avant de l'ajouté à un NSMutableArray. Et pour finir, même en étant rigoureux, l'utilisation de la méthode "respondsToSelector:" (qui soit dit en passant n'est pas spécifique à NSObject) n'est pas nécessaire et peut même aussi induire en erreur, car bien que cette méthode retourne NO, l'objet peut très bien répondre à la méthode via, notamment, d'objets délégués, c'est tout le principe de la redirection qui n'est pas non plus réservé à NSObject, bien au contraire.
Ah parce qu'en Objective-C on ne peut pas déclarer de tableau d'objets peut-être ? Il faudrait alors me dire comment vous envisagez le stockage des éléments dans un NSArray... Un objet étant toujours alloué dynamiquement en Objective-C il suffit de déclarer un tableau de pointeur sur objet, si tu veux le type de base : id *tableauDObjet, si tu veux te faire un tableau de NSObject : NSObject **tableaudeNSObject. Notez par ailleurs que NSObject et id sont deux choses totalement différentes, car bien qu'il est conseillé de faire hériter ses objets directement, ou indirectement, de NSObject, ce n'est pas obligatoire, il existe d'ailleurs plusieurs classes racines dans Cocoa (NSObject et NSProxy...)
Les électeurs, type SEL, ne sont pas des pointeurs de méthode ! Les sélecteurs sont des identifiants de méthodes, ce n'est pas pareil. Un pointeur de méthode en Objective-C c'est le type IMP, définit comme ça : typedef id (*IMP)(id, SEL, ...); Il est utile en général pour faire plusieurs appels à la même méthode sur le même objet (ou sur un objet qui répond exactement à la même méthode) genre dans une boucle par exemple, pour éviter de passer par le système de vérification à chaque tour. L'héritage multiple du C++ peut-être facilement reproduit par des objets qu'on pourrait qualifier de "délégué", on peut par exemple utiliser un objet, dont on connaà®t le type, dans un autre pour lui envoyer plusieurs méthodes, et bien sûr inutiles de redéfinir toutes ses méthodes il suffit de faire de la redirection.
Je conteste l'utilisation du mot "particulièrement" devant "lent", en effet, le fait de devoir rechercher quelle méthode utiliser à chaque fois ralentit l'envoie des messages, cependant, en plus du contournement que j'ai cité plus haut, le runtime met les méthodes qu'il a déjà exécuté dans une cache qui permet d'accélérer la redirection, ce qui fait qu'un envoie de message devient pratiquement aussi rapide qu'un appel à une fonction C. Et après, un certains temps d'utilisation d'une application objective-c la majorité des messages sont cachés et permettent une utilisation optimale.
rassure-toi il n'y a sur ce site que de fervents admirateurs d'Obj-C, admirateurs, mais en connaissance de cause ..
et depuis quand un nouveau ne paye pas sa tournée ??Â