›

Cocoa ou Foundation ?

tabliertablier Membre
dans Xcode et Developer Tools #1
Je viens de démarrer un projet (Mac OSx) avec Xcode 4.3.2 sous 10.7.5.

Le fichier AppDelegate.h du projet importe bien Cocoa.h : #import <Cocoa/Cocoa.h>

J'ajoute des fichiers en sélectionnant "Objective-C class" dans la fenêtre de choix des "Templates".

Dans tout ces fichiers l'import est: #import <Foundation/Foundation.h>

Il me semble que c'est une erreur.

Bien sur, je peux corriger, mais j'aimerais bien connaitre le pourquoi de cette chose qui me parait illogique. Vous avez un avis?

Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    Qu'est ce que tu as comme #import dans ton Precompiled Header (prefix.pch) ?

    Si tu as Cocoa.h d'importé dans ton Precompiled Header tu n'as pas de soucis à  te faire, il sera importé dans tous tes .h automatiquement.
  • tabliertablier Membre
    #3
    Effectivement l'import dans le [font=helvetica, arial, sans-serif]Precompiled Header (prefix.pch) est [/font]

    #ifdef __OBJC__

    #import <Cocoa/Cocoa.h>

    #endif



    et ça répond à  ma question. Mais quand même, demander une classe Cocoa et avoir un import de Foundation ça surprend.
  • CéroceCéroce Membre, Modérateur
    #4
    Non, ce n'est pas surprenant.

    Cocoa = Foundation + AppKit/UIKit.



    Si on travaille sur des classes Modèle, alors on n'a pas besoin des classes de l'IHM.
  • yoannyoann Membre
    #5
    Oui c'est même tout à  fait logique, tant qu'on a pas une sous classe d'un objet d'UI on définie nos nouvelles classe avec un importe de Foundation.



    Si on a besoin d'ivar ou de méthodes avec des arguments provenant de AppKit, on définie le symbole en @class et on fait l'import approprié dans l'implémentation. Cela évitera des imports trop lourd lorsque notre .h sera utilisé.
  • tabliertablier Membre
    #6
    J'ai été surpris pour deux raisons:

    Dans ce cas d'ajout de fichier, sous les Xcode précédents l'import était Cocoa.h.

    J'accède au objets du .nib, donc l'import de Cocoa.h me paraissait plus normal.
  • yoannyoann Membre
    #7
    'tablier' a écrit:


    J'ai été surpris pour deux raisons:

    Dans ce cas d'ajout de fichier, sous les Xcode précédents l'import était Cocoa.h.

    J'accède au objets du .nib, donc l'import de Cocoa.h me paraissait plus normal.




    Le changement est fait pour mutualiser les template avec iOS.



    Certe on accède au NIB mais on y accède pour un usage interne, donc en toute logique, c'est du @class et un import dans l'implémentation.
  • muqaddarmuqaddar Administrateur
    #8
    J'en profite pour demander à  quoi sert réellement :





    #ifdef __OBJC__



    avant les imports.



    Je présume que ça veut dire "Si on est dans un projet Objective-C..." ?



    Parce que j'importe des fichiers.h dans le préfix.pch, mais je ne les mets pas dans cette condition, qui n'a pas l'air importante...
  • yoannyoann Membre
    #9
    'muqaddar' a écrit:


    J'en profite pour demander à  quoi sert réellement :





    #ifdef __OBJC__



    avant les imports.



    Je présume que ça veut dire "Si on est dans un projet Objective-C..." ?



    Parce que j'importe des fichiers.h dans le préfix.pch, mais je ne les mets pas dans cette condition, qui n'a pas l'air importante...




    Si le fichier dans lequel on est importé est en ObjC.



    Le pch est un header commun à  tous les fichiers compilé de l'application, si tu as des bouts de code C et que tu fait un import non protégé tu aura l'import de fait dans le code C sans pour autant avoir un compilo qui accepte cette syntaxe.
  • tabliertablier Membre
    #10
    Hi hi hi!

    @Yoann Je te prends à  faire une faute pas évidente du tout parce que la faute ne change pas la prononciation de la phrase:
    ...tant qu'on a pas une sous classe d'un objet d'UI....
    Tu as trouvé?

    Rassures toi, j'en fais des pires que celle la!
  • muqaddarmuqaddar Administrateur
    #11
    'yoann' a écrit:


    Si le fichier dans lequel on est importé est en ObjC.



    Le pch est un header commun à  tous les fichiers compilé de l'application, si tu as des bouts de code C et que tu fait un import non protégé tu aura l'import de fait dans le code C sans pour autant avoir un compilo qui accepte cette syntaxe.




    OK, merci.
  • AliGatorAliGator Membre, Modérateur
    #12
    'yoann' a écrit:


    Si le fichier dans lequel on est importé est en ObjC.



    Le pch est un header commun à  tous les fichiers compilé de l'application, si tu as des bouts de code C et que tu fait un import non protégé tu aura l'import de fait dans le code C sans pour autant avoir un compilo qui accepte cette syntaxe.
    Oui je suis d'accord avec cette logique et cette explication.



    Pourtant, en pratique, j'ai déjà  eu des problèmes avec Xcode en mettant des #import à  l'intérieur de ce #ifdef, sur 2 projets récemment.
    • En mettant mon #import "OHMacros.h" à  l'intérieur du #if pour avoir mes petites macros personnalisées accessibles partout dans mon code, parfois Xcode après une compilation de on code semblait le compiler une 2e fois... et me mettait des pastilles rouges en face des lignes où j'utilisais mes macros. Pourtant quand je regardais dans le build log elles n'y étaient pas. Mais quand je cliquais sur les pastilles rouges dans la marge à  gauche de mon code source, il me mettait des erreurs comme si les macros n'étaient pas définies et lui étaient inconnues. Un peu comme s'il avait compilé une fois et que tout s'était bien passé, et qu'ensuite CodeSense avait refait une passe (à  sa façon compilation JIT) mais n'avait cette fois-ci pas importé mon OHMacros.h de mon pch.
    • J'ai mis longtemps à  comprendre, cherchant pourquoi il n'importait pas mon pch et donc les OHMacros.h qui étaient importés dedans au passage... Et puis j'ai sorti mon #import "OHMacros.h" du #ifdef __OBJC__ et là  le problème a disparu...


    Bug de Xcode (ou de CodeSense) ? J'en sais rien mais du coup ça m'a perdu pas mal de temps ce truc à  l'époque...
  • yoannyoann Membre
    #13
    'tablier' a écrit:


    Hi hi hi!

    @Yoann Je te prends à  faire une faute pas évidente du tout parce que la faute ne change pas la prononciation de la phrase: Tu as trouvé?

    Rassures toi, j'en fais des pires que celle la!






    En effet, cela dit je suis très mauvais à  l'écris ^^



    ...tant qu'on n'a pas une sous classe d'un objet d'UI....
  • yoannyoann Membre
    #14
    'AliGator' a écrit:


    Oui je suis d'accord avec cette logique et cette explication.



    Pourtant, en pratique, j'ai déjà  eu des problèmes avec Xcode en mettant des #import à  l'intérieur de ce #ifdef, sur 2 projets récemment.
    • En mettant mon #import "OHMacros.h" à  l'intérieur du #if pour avoir mes petites macros personnalisées accessibles partout dans mon code, parfois Xcode après une compilation de on code semblait le compiler une 2e fois... et me mettait des pastilles rouges en face des lignes où j'utilisais mes macros. Pourtant quand je regardais dans le build log elles n'y étaient pas. Mais quand je cliquais sur les pastilles rouges dans la marge à  gauche de mon code source, il me mettait des erreurs comme si les macros n'étaient pas définies et lui étaient inconnues. Un peu comme s'il avait compilé une fois et que tout s'était bien passé, et qu'ensuite CodeSense avait refait une passe (à  sa façon compilation JIT) mais n'avait cette fois-ci pas importé mon OHMacros.h de mon pch.
    • J'ai mis longtemps à  comprendre, cherchant pourquoi il n'importait pas mon pch et donc les OHMacros.h qui étaient importés dedans au passage... Et puis j'ai sorti mon #import "OHMacros.h" du #ifdef __OBJC__ et là  le problème a disparu...


    Bug de Xcode (ou de CodeSense) ? J'en sais rien mais du coup ça m'a perdu pas mal de temps ce truc à  l'époque...






    J'ai eu le même type de soucis. L'analyse de code durant l'écriture gère très mal le PCH, je m'en suis rendu compte avec mes macro de log.
  • AliGatorAliGator Membre, Modérateur
    #15
    Bon tu me rassures je suis pas le seul.



    Donc ça sent le bug de CodeSense (qui ne prend pas en compte le __OBJC__ quand il compile JIT à  la volée) c'est nul ça... et du coup seule solution mettre le #import à  l'extérieur du #ifdef... autrement dit on perd tout l'intérêt de ce #ifdef... c'est bien la peine !
Connectez-vous ou Inscrivez-vous pour répondre.