Doit on systématiquement faire un import de Foundation.h ou Cocoa.h ?

Réponses

• aranaud Membre

  décembre 2005 10:17 modifié #2

  Moi, je le mes systématiquement. En fait, c'est plutot Xcode qui le met.
  Si ta classe ne fait pas appelle au fonction de Cocoa, tu n'est pas obligé de le mettre (par ex : une classe en C pur).
• AliGator Membre, Modérateur

  décembre 2005 10:17 modifié #3

  Ceci dit il est très rare de ne pas utiliser les fonctions et classes de Cocoa ou du FundationKit.
  un NSString par-ci, un NSChose par là ... déjà  hop t'es obligé d'avoir Cocoa dans tes headers.
  
  En effet à  part un fichier en C pur, il reste assez rare de ne pas avoir besoin de ces headers qui contiennent la base des frameworks Apple, donc les fonctions qu'on utilise tellement souvent dans nos programmes sous Xcode que ça en est souvent devenu des standards (il est même parfois difficile de faire la différence entre les choses propres à  l'Objective-C et celles apportées par les frameworks Apple )
• aranaud Membre

  décembre 2005 10:17 modifié #4

  Dès que tu fais appelle à  une fonction qui fait partie d'une autre classe ou d'un frameworks, tu dois importé une fichier queque.h. C'est pour indiquer d'où vient c'est fonction utilisé dans ton application.
• zenx Membre

  décembre 2005 10:17 modifié #5

  Ok les gars, je vous ai bien suivi. Mais, dans l'hypothèse d'un projet qui comporterait un main.c et 4 classes (donc 4 autres fichiers .h et .c), dès l'instant ou j'ai fait un import de cocoa.h dans une des classes ou même dans le header du main, n'est ce pas redondant et inutile de le répeter dans les autres header de mes classes (effectivement XCode par défaut lorsqu'on rajoute une nouvelle classe crée un .h et un .c avec l'import de cocoa.h ou de foundation selon le type de projet) ?.
• Eddy58 Membre

  décembre 2005 décembre 2005 modifié #6

  Normalement, si tu as un fichier .pch (créé avec le projet), tu n'as pas besoin de faire l'import (qui est obligatoire) dans chacune de tes classes, car les imports de ce fichier s'ajouteront à  ceux spécifiques à  chaque classe.
  [tt]
  #ifdef __OBJC__
      #import <Cocoa/Cocoa.h>
  #endif
  [/tt]
  
  [EDIT]

  
  Mais, dans l'hypothèse d'un projet qui comporterait un main.c et 4 classes (donc 4 autres fichiers .h et .c)

  
  Je pense que tu veux plutôt parler de main.m (et donc 4 autres fichiers .h et .m) ? ::)
• AliGator Membre, Modérateur

  décembre 2005 10:17 modifié #7

  Si les classes interviennent "à  tout va", un peu partout dans ton projet de façon croisée par exemple, il peut être utile de créer un header spécial qui groupe les #import communs à  tous les .h.
  Donc dans ce "common.h" si on l'appelle comme ça tu mets #import <Cocoa/Cocoa.h> mais aussi #import "classe1.h", #import "classe2.h" etc.
  Et ensuite dans tes .m tu peux importer "common.h" plutôt que de réimporter toujours la même liste de fichiers ".h"
  Si en plus tu précompiles ce header (common.pch que tu rajoutes dans la liste des headers précompilés, ou un truc du genre, j'avoue n'avoir jamais trop fait joujou avec les pch de ce côté) tu pourras en plus y gagner à  la compil'.
  
  Cependant dans tout .m il y a au moins un .h qui va dire dans quel fichier se trouvent les déclarations des fonctions/méthodes/messages que tu vas définir... ou appeler. C'est incontournable d'avoir des ".h", et pour ce qui est de "Cocoa.h" vu le nombre de fonctions Cocoa que tu utilises (sans t'en rendre trop compte sans doute) c'est quasi obligé
• zenx Membre

  décembre 2005 10:17 modifié #8

  Merci messieurs pour vos réponses et joyeux Noël à  tous !!