Protocol et library
groumpf
Membre
Salut,
j'ai une librarie qui utilise une autre librarie, et en particulier un viewController qui implémente un Protocol de l'autre librairie.
Comment faire pour limiter voir supprimer le besoin d'inclure (pour l'utilisateur de ma librairie) les .h de l'autre librairie ?
Pour les membres de la classe je peux utiliser @class mais pour le protocol je ne vois pas comment faire :
D'une manière générale je suis étonné qu'on soit obligé de divulguer autant de choix d'implémentation dans les .h. En fait ce que je voudrais c'est masquer totalement l'implémentation mais je sens que c'est impossible.
j'ai une librarie qui utilise une autre librarie, et en particulier un viewController qui implémente un Protocol de l'autre librairie.
Comment faire pour limiter voir supprimer le besoin d'inclure (pour l'utilisateur de ma librairie) les .h de l'autre librairie ?
Pour les membres de la classe je peux utiliser @class mais pour le protocol je ne vois pas comment faire :
<br />@class AutreLib_A;<br /><br />@interface MonViewController : UIViewController <AutreLib_Protocol><br />{<br /> AutreLib_A *a;<br />}<br />@end<br />D'une manière générale je suis étonné qu'on soit obligé de divulguer autant de choix d'implémentation dans les .h. En fait ce que je voudrais c'est masquer totalement l'implémentation mais je sens que c'est impossible.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
http://pommedev.mediabox.fr/frameworks-communs-objective-c/probleme-de-references-croisees-sur-delegates/msg69387/#msg69387
De toute façon la lib AutreLib est déjà "dévoilée" par le nom des classes.
C'est vraiment de la bidouille pour des problèmes simples. Je me demande si Eiffel est mieux à ce niveau. Bref. Merci quand même.
Je fais pareil, c'est juste pour faire raler Céroce. >:D ;D
A ce propos, il m'est arrivé un truc inattendu : quand j'ai inclu les 2 .a (le mien et l'autre) dans une appli de test, xcode m'a sorti une erreur duplicate entry.
J'ai supprimé l'autre .a et tout a marché.
Quelqu'un peut me confirmer que c'est normal (!), quand j'ai compilé mon .a, xcode à intégré le code de l'autre .a ?
Je me voyais faire des manips avec lipo mais ça semble inutile.
Enfin ça dépend comment est foutue ta librairie .a en fait.
Si tu as une librairie libA.a et une librairie libB.a qui, comme tu dis "dépend de libA.a", certainement que quand tu compiles libB.a elle inclus dans son code libA.a. C'est le propre des librairies statiques (comparativement aux librairies dynamiques), quand on link avec une librairie statique, on ne fait qu'inclure directement son code compilé dans le produit que l'on link.
Si tu link une application avec une librairie libX.a, une fois l'appli compilée, tout le code de la librairie libX.a est inclus en dur dans le code de l'appli compilée (tu peux supprimer libX.a l'appli continuera de fonctionner, le code de libX a été copié dans le code de l'app).
De la même manière si tu link une librairie libB.a avec une librairie libA.a, une fois la librairie B compilée, tout le code de la librairie libA.a est inclus en dur dans le code de la librairie libB que tu viens de produire.
Et du coup bien sûr si tu link ensuite une application avec cette libB, cette libB contient tout le code de libB... et le code de libA aussi qu'elle a copié quand tu as compilé libB... donc du coup comme il y a déjà tout le code compilé de libA dans libB il ne faut pas relinker ton appli aussi avec libA, sinon tout le code de libA serait inclus 2 fois (d'où le "duplicate entry"). C'est logique.
Bien sûr si tu fonctionnais avec des librairies dynamiques, cela ne serait plus vrai, quand on link avec une dylib le code n'est que référencé, pas copié.
en fait j'ai du le faire par hasard puisque j'ai intégré la libA dans le projet de la libB alors que les headers auraient suffit j'imagine pour juste compiler la libB (à condition à ce moment d'ajouter la libA dans l'application finale).
En tout cas ça résout un de mes problèmes.