Pourquoi n'est-ce pas ProjectName-Préfixe.pch créée automatiquement dans Xcode 6?

Pourquoi n'est-ce pas ProjectName-Prefix.pch créé automatiquement dans Xcode 6 ?

Est le précompiler en-tête n'est plus nécessaire ?

Où dois-je écrire le code qui était dans ProjectName-Prefix.pch avant ?

InformationsquelleAutor Wei | 2014-06-11

135

Je soupçonne en raison de modules, ce qui élimine la nécessité pour le #import <Cocoa/Cocoa.h>.

Où mettre le code que vous mettez dans un préfixe en-tête, il n'y a pas de code, vous devrez entrer un préfixe en-tête. Mettez votre importations dans les fichiers qui en ont besoin. Mettez vos définitions dans leurs propres fichiers. Mettez vos macros...nulle part. Arrêter d'écrire des macros à moins qu'il n'y a pas d'autre moyen (comme quand vous en avez besoin __FILE__). Si vous avez besoin de macros, les mettre dans un en-tête et de l'inclure.

Le préfixe en-tête a été nécessaire pour les choses qui sont énormes et utilisé par presque tout dans l'ensemble du système (comme Foundation.h). Si vous avez quelque chose d'énorme et omniprésents, vous devez repenser votre architecture. Préfixe en-têtes de rendre la réutilisation du code dur, et d'introduire de subtils problèmes de compilation si l'un des fichiers ci peut changer. Les éviter jusqu'à ce que vous avez un sérieux moment de la construction du problème que vous pouvez démontrer est nettement améliorée avec un préfixe en-tête.

Dans ce cas, vous pouvez en créer un et la passer dans clang, mais c'est très rare, que c'est une bonne idée.

EDIT: À votre question précise sur un HUD vous utiliser dans toutes vos contrôleurs de vue, oui, vous devez absolument l'importer dans chaque vue-contrôleur qui en fait l'utilise. Cela rend les dépendances clair. Lorsque vous réutilisez votre point de vue contrôleur dans un nouveau projet (qui est commun, si vous construisez votre contrôleurs de), vous saurez immédiatement ce que cela implique. C'est surtout important pour les catégories, ce qui peut rendre le code très difficile à réutiliser si elles sont implicites.

De la PCH fichier n'est pas là pour se débarrasser de la liste des dépendances. Vous devriez toujours importer UIKit.h ou Foundation.h en tant que de besoin, que la Xcode modèles. La raison de la PCH est d'améliorer les temps de construire lorsqu'ils traitent avec vraiment massive des en-têtes (comme dans UIKit).
- Je suis d'accord pour faire de la .pch fichier propre, mais je suis confus, dans certaines situations, par exemple, j'utilise SVProgressHUD, presque tous les ViewController besoin de l'appeler, donc dois-je importer SVProgressHUD.h dans tous les ViewController ? ou créer un BaseViewController et l'importation SVProgressHUD.h ? Categorys ont la même situation. Pourriez-vous me donner une suggestion?
- votre réponse est subjective diatribe. Je ne suis pas d'accord, il devrait être accepté comme une réponse à cette question. Comment voulez-vous mettre en place quelque chose comme ceci github.com/seancook/TWReverseAuthExample/blob/... sans pch ? Importer le journal dans chaque fichier? Cela crée tout un tas d'inutiles gonfler dans votre code.
- Chaque fichier qui utilise en fait que de la macro, oui (dans mon expérience, c'est en général moins que tous les fichiers dans le système). C'est un très bon exemple de mon point de vue. L'importation implicitement masque le fait que vous avez une dépendance sur cet enregistrement de la macro. Lorsque vous essayez de copier TWAPIManager.m, par exemple, pour un autre projet, vous obtiendrez des erreurs que TWALog() n'est pas défini, avec aucun indice sur l'endroit où le trouver. J'ai rencontré exactement ce problème sur plusieurs projets d'envergure en essayant de partager du code. La création de TWAPILog.h et de l'importer résout ce avec trivial dev coût.
- Dans le cas de l'importation de UIKit, cependant, que si vous vouliez créer une classe qui implémente l' UITableViewDelegate protocole? Souhaitez-vous @import UIKit pour juste que la classe, ou serait-ce un cas nécessaire pour une PCH? Votre réponse, "au besoin", n'est pas vraiment clair.
- Si vous avez besoin de UIKit fonctionnalité dans une classe, il importer UIKit. Si vous ne le faites pas, il doit importer de la Fondation. Si vous avez besoin d'AppKit fonctionnalité, vous pouvez importer de Cacao. Qui garde le code plus réutilisable (je partage beaucoup de code entre iOS et OS X et recommande aux gens de ne pas la boîte de soi que, pour aucun but). Vous serait toujours inclure UIKit dans la PCH (lorsque les modules ne sont pas disponibles), mais seulement d'améliorer les temps de construire.
- J'utilise ReactiveCocoa dans presque toutes les classes, il faudrait être folle pour moi de ne pas utiliser un fichier pch...
- Je suis avec Rob sur ce, l'importation d'où le besoin est le plus propre meilleur chemin pour gérer les dépendances. Si vous vraiment besoin de gérer les choses plus simples, vous devriez regarder votre propre Cadre (toujours besoin d'importer ce chiot, où il est utilisé) ou encore un module...
- Non seulement les modules, mais swift est probablement un gros morceau.
- Comment voulez-vous faire des Rapports d'incidents, comme la Nouvelle de Relique sans l'ajouter à la PCH? Ils ont vraiment besoin d'être dans tout ce que vous pouvez voir où le bug vient.
- Je ne vois pas comment le rapport d'incident est lié. L'importation d'un fichier d'en-tête déclare simplement de fonctions et de classes pour vous. Il ne fait pas de provoquer quelque chose à exécuter. Ne vous faites spécifiques NewRelic appels dans chaque fichier? Qui semble très étrange. En regardant leurs docs, je ne vois qu'un appel nécessaire à leur bibliothèque (qui est ce que je m'attends). Avez-vous essayé sans passer par la pch?
- Comment à propos des catégories? À mon humble avis, son stupide d'avoir à importer une douzaine de fichiers dans chaque vue-contrôleur par exemple, si vous avez un grand nombre de catégories.
- La clé est que la PCH est un en-tête précompilé. Pré-compilation est pour construire la performance, pas de disponibilité automatique. Pré-compilation introduit plusieurs façons de gâcher votre construction, et devrait être réservé pour les grandes choses que jamais changement entre le non-propre s'appuie (comme la Fondation).
- Rob .. bizarre que vous n'utilisez pas les Macros, mon pote ! Programmation sans un préprocesseur est comme, euh, eh bien, il n'est pas bon.
- Tout le reste Rob dit ici est correcte, bien sûr.
- Ce que les macros pour supprimer NSLog pour une configuration de version?
- J'utilise toujours mon propre journalisation macro qui peut être retiré ou reconfiguré dans différentes configs. Mettre cette macro dans un en-tête; importation de l'en-tête où vous l'utilisez. Même si j'ai cru à l'aide de la pch pour ce genre de macro, je n'aurais jamais écrire une macro pour redéfinir NSLog lui-même. La réécriture des fonctions standard est très déroutant.
- Je voulais vous demander ce qui doit être fait si il y a disons un fichier de constantes, qui je le sais, sera utilisé par le projet ? Est-il une alternative à l'utilisation d'un préfixe ou d'utiliser un préfixe pour un si petit fichier est ok ?
- généralement les constantes doivent être conservés avec les choses de la configuration (dans le même fichier ou dans un étroitement liées fichier importé par la configuration de l'objet de l'en-tête) et importés par ces choses, ils les utilisent. En général, il ne devrait pas être un "système" constantes de fichier rempli avec sans rapport avec les constantes. C'est très préjudiciable pour la réutilisation du code. La plupart des constantes comme "MySpecialColor" doit être catégories (sur UIColor dans ce cas). Et de styles et mises en page doit être passé comme des objets ou des actifs configurateurs que les choses lorsque cela est possible, plutôt que de compter sur global autonome des constantes.
- hmmm aight merci, je pense que j'ai compris l'essentiel de il.
- Bien Sûr, Rob. comme l'exploitation forestière. DLog est certainement quelque chose qui devrait aller dans une .pch, à moins de vous proposer une alternative. Vous dites que les modules de faire un pch hors de propos, mais vous ne dites pas pourquoi. Le confort nous voulons de la .pch est tout simplement de sorte que nous N'AVONS PAS D'importer un autre en-tête de partout pour quelque chose que nous voulons être disponibles partout.
InformationsquelleAutor Rob Napier
425

Sans la question de savoir si il est bon ou non, vous pouvez ajouter de la PCH fichier manuellement:
1. Ajouter de nouveaux PCH fichier au projet: Nouveau fichier > Autres > PCH fichier.
2. À la Cible Paramètres de construction de la option, définissez la valeur de Préfixe en-Tête à votre PCH nom de fichier, le nom du projet en tant que préfixe (c'est à dire pour un projet nommé TestProject et PCH fichier nommé MyPrefixHeaderFile, ajouter de la valeur TestProject/MyPrefixHeaderFile.pch à la plist).
  
  ASTUCE: Vous pouvez utiliser des choses comme $(SRCROOT) ou $(PROJECT_DIR) pour obtenir le chemin d'accès de l'endroit où vous mettez le .pch dans le projet.
3. À la Cible Paramètres de construction de la option, définissez la valeur de Précompiler Préfixe en-Tête à YES.
- Malgré mes avis sur la PCH fichiers, +1. Il est toujours utile de savoir comment utiliser les outils.
- Je voulais juste dire un petit merci de prendre le temps de communiquer la réponse à la question en dépit de jugements que vous avez sur elle. J'apprécie quand les gens prennent le temps pour vous de répondre à des questions plutôt que de simplement s'en prendre à la personne sur la façon dont à mauvais escient, la question est de.
- Merci. Je trouve qu'il est utile lors de l'incorporation de certains de mes Objective-C dans un Swift projet, donc je n'ai pas à revenir en arrière et ajouter un tas de fichiers à inclure pour chacun de ceux-ci .m fichiers.
- Très pratique lors de la transition d'ObjC Swift - j'ai un tas de bibliothèques écrites en ObjC et la dernière chose que je veux faire est de modifier tous pour inclure le système de droit les en-têtes.
- Cela n'a pas fonctionné pour moi cause j'ai utilisé les paramètres de construction. Cependant, lorsque j'ai suivi ce instructinos de modifier le Projet de Construire des Paramètres au lieu de cela, tout a fonctionné.
- C'est la vraie réponse.
- non, il n'est pas. Cette "réponse" est utile, mais ne pas répondre à l'OP question: POURQUOI n'est pas ProjectName-Préfixe.pch créée automatiquement dans Xcode 6??
- Prakash la réponse est encore mieux!
InformationsquelleAutor Yedidya Reiss
126

Vous avez besoin pour créer vos propres PCH fichier

Ajouter New file -> Other-> PCH file

Puis ajoutez le chemin d'accès de ce fichier PCH de votre construction setting->prefix header->path

($(SRCROOT)/nom de fichier.pch)
- Ainsi, en fonction du travail dir, les variables peuvent varier. Je suis à l'aide de $(PRODUCT_DIR)/$(PRODUCT_NAME)/PrefixHeader.pch
- Si vous gardez le .pch fichier dans le dossier particulier, puis la situation s'est produite.
InformationsquelleAutor Prakash Raj
51

Je vais vous montrer avec un pic!!!
1. Ajouter un nouveau Fichier
2. Aller à Projet/Paramètre de construction/APPl LLVM 6.0 Langue
InformationsquelleAutor Slemon
23

À ajouter .pch fichier-

1) Ajouter une nouvelle .pch fichier à votre projet->Nouveau fichier->autre->fichier PCH

2) Goto votre projet de construction de réglage.

3) la Recherche "préfixe en-tête". Vous pouvez trouver qu'en vertu de l'Apple LLVM.

4) Collez le dans le champ $(SRCROOT)/yourPrefixHeaderFileName.pch

5) Nettoyer et de construire le projet.
Ça y est!!!

InformationsquelleAutor Subham93
12

Si vous décidez d'ajouter un .pch fichier manuellement et que vous voulez utiliser Objective-C, juste avant de xCode 6, vous aurez également à l'importation UIKit et de la Fondation de cadres de dans le .pch fichier. Sinon, vous devrez importer ces cadres manuellement dans chaque fichier d'en-tête. Vous pouvez ajouter le code suivant de toute façon comme il teste la langue utilisée:
```
#ifdef __OBJC__
    #import <UIKit/UIKit.h>
    #import <Foundation/Foundation.h>
#endif
```
- Tout ce qui implique ObjC code doit être placé à l'intérieur de la au-dessus de #ifdef _ OBJC,_, sinon vous aurez des erreurs à partir de sources C (dans le cas où vous avez ces sources) que vous ne comprendrez jamais
InformationsquelleAutor mgm
7

Utilisation :

$(PROJECT_DIR)/nom du Projet/PrefixHeader.pch
- N'importe quel $ type de déclaration existe pour "Nom de Projet" ??
InformationsquelleAutor Arash Zeinoddini
7

Pour ajouter un nouveau fichier PCH suivre soufflet suit :

(1) Ajouter une Nouvelle fiew - Sélectionnez iOS - Autres et PCH Fichier

(2) ajouter le chemin d'accès de ce fichier PCH à votre Projet - BuildSetting - Apple LLVM 6.0 Langue

Ajouter Définir le Préfixe en-Tête de Chemin Nom_application(root-path)/nom de fichier.pch
- Veuillez indiquer la dernière. Ajouter définir le préfixe en-tête de chemin.
InformationsquelleAutor Hitesh Vaghela

Vous devez vous connecter pour publier un commentaire.