Quelle est la différence entre #import et #include dans Objective-C?

Quelles sont les différences entre #import et #include dans Objective-C et y a-t-il des moments où vous devez les utiliser les uns par rapport aux autres? Est-on obsolète?

Je lisais le tutoriel suivant: http://www.otierney.net/objective-c.html#preamble et son paragraphe sur #import et #include semble se contredire ou du moins n'est pas clair.

La directive #import a été ajoutée à Objective-C en tant que version améliorée de #include. L'amélioration ou non, cependant, fait toujours débat. #import garantit qu'un fichier n'est inclus qu'une seule fois afin que vous n'ayez jamais de problème avec les inclusions récursives. Cependant, la plupart des fichiers d'en-tête décents se protègent de toute façon contre cela, ce n'est donc pas vraiment un avantage.

Fondamentalement, c'est à vous de décider lequel vous souhaitez utiliser. J'ai tendance à #importer les en-têtes pour les choses Objective-C (comme les définitions de classe et autres) et #inclure les éléments C standard dont j'ai besoin. Par exemple, l'un de mes fichiers source pourrait ressembler à ceci:

#import <Foundation/Foundation.h>

#include <asl.h>
#include <mach/mach.h>

Il semble y avoir beaucoup de confusion concernant le préprocesseur.

Ce que fait le compilateur lorsqu'il voit #includequ'il remplace cette ligne par le contenu des fichiers inclus, aucune question n'est posée.

Donc, si vous avez un fichier a.havec ce contenu:

typedef int my_number;

et un fichier b.cavec ce contenu:

#include "a.h"
#include "a.h"

le fichier b.csera traduit par le préprocesseur avant la compilation en

typedef int my_number;
typedef int my_number;

ce qui entraînera une erreur de compilation, car le type my_numberest défini deux fois. Même si la définition est la même, cela n'est pas autorisé par le langage C.

Comme un en-tête est souvent utilisé à plusieurs endroits, les gardes sont généralement utilisés en C. Cela ressemble à ceci:

 #ifndef _a_h_included_
 #define _a_h_included_

 typedef int my_number;

 #endif

Le fichier b.ccontiendrait toujours l'intégralité du contenu de l'en-tête deux fois après avoir été prétraité. Mais la deuxième instance serait ignorée car la macro _a_h_included_aurait déjà été définie.

Cela fonctionne vraiment bien, mais présente deux inconvénients. Tout d'abord, les gardes d'inclusion doivent être écrits et le nom de la macro doit être différent dans chaque en-tête. Et deuxièmement, le compilateur doit toujours chercher le fichier d'en-tête et le lire aussi souvent qu'il est inclus.

Objective-C possède l' #importinstruction de préprocesseur (elle peut également être utilisée pour le code C et C ++ avec certains compilateurs et options). Cela fait presque la même chose #include, mais il note également en interne quel fichier a déjà été inclus. La #importligne est uniquement remplacée par le contenu du fichier nommé pour la première fois qu'il est rencontré. Chaque fois après cela, il est simplement ignoré.

Je suis d'accord avec Jason.

Je me suis fait prendre en faisant ça:

#import <sys/time.h>  // to use gettimeofday() function
#import <time.h>      // to use time() function

Pour GNU gcc, il se plaignait que la fonction time () n'était pas définie.

Alors j'ai changé #import en #include et tout s'est bien passé.

Raison:

Vous #importez <sys / time.h>:
    <sys / time.h> inclut uniquement une partie de <time.h> en utilisant #defines

Vous #importez <time.h>:
    Non, allez. Même si seulement une partie de <time.h> était déjà incluse, en
    ce qui concerne #import, ce fichier est maintenant déjà complètement inclus.

Conclusion:

Les en-têtes C / C ++ incluent traditionnellement des parties d'autres fichiers include.
Donc, pour les en-têtes C / C ++, utilisez #include.
Pour les en-têtes objc / objc ++, utilisez #import.

#includefonctionne comme le C #include.

#importconserve la trace des en-têtes déjà inclus et est ignoré si un en-tête est importé plusieurs fois dans une unité de compilation. Cela rend inutile l'utilisation de protecteurs d'en-tête.

Le résultat est simplement utilisé #importdans Objective-C et ne vous inquiétez pas si vos en-têtes finissent par importer quelque chose plus d'une fois.

Je sais que ce fil est vieux ... mais dans "les temps modernes" .. il y a une "stratégie d'inclusion" bien supérieure via les @importmodules de clang - qui est souvent négligée ..

Les modules améliorent l'accès à l'API des bibliothèques de logiciels en remplaçant le modèle d'inclusion textuel du préprocesseur par un modèle sémantique plus robuste et plus efficace. Du point de vue de l'utilisateur, le code n'est que légèrement différent, car on utilise une déclaration d'importation plutôt qu'une directive de préprocesseur #include:

@import Darwin; // Like including all of /usr/include. @see /usr/include/module.map

ou

@import Foundation;  //  Like #import <Foundation/Foundation.h>
@import ObjectiveC;  //  Like #import <objc/runtime.h>

Cependant, cette importation de module se comporte assez différemment de la #include correspondante: lorsque le compilateur voit l'importation de module ci-dessus, il charge une représentation binaire du module et met son API à la disposition de l'application directement. Les définitions de préprocesseur qui précèdent la déclaration d'importation n'ont aucun impact sur l'API fournie ... car le module lui-même a été compilé en tant que module autonome distinct. De plus, tout indicateur de l'éditeur de liens requis pour utiliser le module sera automatiquement fourni lors de l'importation du module. Ce modèle d'importation sémantique résout de nombreux problèmes du modèle d'inclusion de préprocesseur.

Pour activer les modules, passez l'indicateur de ligne de commande -fmodulesaka CLANG_ENABLE_MODULESin Xcode- au moment de la compilation. Comme mentionné ci-dessus .. cette stratégie évite TOUT et TOUS LDFLAGS. Comme dans, vous pouvez SUPPRIMER tous les paramètres "OTHER_LDFLAGS", ainsi que toutes les phases de "liaison".

Je trouve que les temps de compilation / lancement se "sentent" beaucoup plus rapides (ou peut-être, il y a juste un peu moins de retard lors de la "liaison"?) .. et fournit également une excellente occasion de purger le fichier Project-Prefix.pch désormais superflu, et paramètres de construction correspondants, GCC_INCREASE_PRECOMPILED_HEADER_SHARING, GCC_PRECOMPILE_PREFIX_HEADERet GCC_PREFIX_HEADER, etc.

De plus, bien que cela ne soit pas bien documenté… Vous pouvez créer des module.maps pour vos propres frameworks et les inclure de la même manière pratique. Vous pouvez jeter un oeil à mon repo github ObjC-Clang-Modules pour quelques exemples de mise en œuvre de tels miracles.

Si vous connaissez C ++ et les macros, alors

#import "Class.h" 

est similaire à

{
#pragma once

#include "class.h"
}

ce qui signifie que votre classe ne sera chargée qu'une seule fois lors de l'exécution de votre application.

Dans le cas où j'ai eu une variable globale dans l'un de mes .hfichiers qui causait le problème, et je l'ai résolu en l'ajoutant externdevant.

SI vous #incluez un fichier deux fois dans des fichiers .h, le compilateur donnera une erreur. Mais si vous # importez un fichier plus d'une fois, le compilateur l'ignorera.

#includeil sert à obtenir des "choses" d'un autre fichier à celui #includedans lequel il est utilisé. Ex:

dans le fichier: main.cpp

#include "otherfile.h"

// some stuff here using otherfile.h objects,
// functions or classes declared inside

Le protège-en-tête est utilisé en haut de chaque fichier d'en-tête (* .h) pour éviter d'inclure le même fichier plus d'une fois (si cela se produit, vous obtiendrez des erreurs de compilation).

dans le fichier: otherfile.h

#ifndef OTHERFILE
#define OTHERFILE

// declare functions, classes or objects here

#endif

même si vous mettez #include"otherfile.h" n time dans votre code, celui-ci ne sera pas redéclaré.

#include + guard == #import

#include guard^Wiki - macro guard, header guard ou file guard empêche de doubler un en-tête par unpreprocessorqui peut ralentir un temps de construction

La prochaine étape est

.pch^{[À propos]} =>@import ^{[À propos]}

[#import dans .hou .m]