В чем разница между #import и #include в Objective-C?

#include работает так же, как C #include.

#import отслеживает, какие заголовки уже были включены, и игнорируется, если заголовок импортируется более одного раза в единицу компиляции. Это делает ненужным использование защиты жатки.

Суть в том, что просто используйте #import в Objective-C и не беспокойтесь, если ваши заголовки импортируют что-то более одного раза.

Директива #import была добавлена ​​в Objective-C как улучшенная версия #include. Однако вопрос о том, улучшился он или нет, все еще остается предметом споров. #import гарантирует, что файл всегда включается только один раз, так что у вас никогда не будет проблем с рекурсивным включением. Однако большинство приличных файлов заголовков в любом случае защищают себя от этого, так что на самом деле это не так уж и важно.

По сути, вам решать, что именно вы хотите использовать. Я стараюсь # импортировать заголовки для вещей Objective-C (например, определения классов и т. д.) И # включать стандартные материалы C, которые мне нужны. Например, один из моих исходных файлов может выглядеть так:

#import <Foundation/Foundation.h>

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

#include он использовал для получения "вещей" из другого файла в тот, в котором используется #include. Бывший:

в файле: main.cpp

#include "otherfile.h"

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

Защита заголовков используется в верхней части каждого файла заголовка (* .h), чтобы предотвратить включение одного и того же файла более одного раза (если это произойдет, вы получите ошибки компиляции).

в файле: otherfile.h

#ifndef OTHERFILE
#define OTHERFILE

// declare functions, classes or objects here

#endif

даже если вы поместите #include "otherfile.h" один раз в свой код, он не будет повторно объявлен.

ЕСЛИ вы # включаете файл два раза в файлы .h, компилятор выдаст ошибку. Но если вы # импортируете файл более одного раза, компилятор проигнорирует его.

Похоже, существует большая путаница в отношении препроцессора.

Что делает компилятор, когда видит #include, что он заменяет эту строку содержимым включенных файлов, без вопросов.

Итак, если у вас есть файл a.h с таким содержимым:

typedef int my_number;

и файл b.c с таким содержанием:

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

файл b.c будет транслироваться препроцессором перед компиляцией в

typedef int my_number;
typedef int my_number;

что приведет к ошибке компилятора, поскольку тип my_number определен дважды. Несмотря на то, что определение такое же, это не допускается языком C.

Поскольку заголовок часто используется более чем в одном месте, включить охранников обычно используются в C. Это выглядит так:

 #ifndef _a_h_included_
 #define _a_h_included_

 typedef int my_number;

 #endif

Файл b.c по-прежнему будет содержать все содержимое заголовка дважды после предварительной обработки. Но второй экземпляр будет проигнорирован, поскольку макрос _a_h_included_ уже был бы определен.

Это действительно хорошо работает, но имеет два недостатка. Прежде всего, должны быть написаны включаемые охранники, и имя макроса должно быть различным в каждом заголовке. А во-вторых, компилятору еще нужно искать файл заголовка и читать его так часто, как он включен.

Objective-C имеет инструкцию препроцессора #import (ее также можно использовать для кода C и C++ с некоторыми компиляторами и опциями). Это почти то же самое, что и #include, но также внутренне отмечает, какой файл уже был включен. Строка #import заменяется содержимым указанного файла только при первом обнаружении. Каждый раз после этого просто игнорируется.

Я согласен с Джейсоном.

Меня поймали на этом:

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

Что касается GNU gcc, он продолжал жаловаться на то, что функция time () была не определен.

Затем я изменил #import на #include, и все прошло нормально.

Причина:

Вы #import <sys / time.h>:
     <sys / time.h> включает только часть из <time.h> с помощью # define

Вы #import <time.h>:
    Нет. Несмотря на то, что только часть <time.h> уже была включена, as
    far, что касается #import, этот файл теперь уже полностью включен.

Нижняя граница:

Заголовки C / C++ традиционно включают части других включаемых файлов. Поэтому для заголовков C / C++ используйте # include.
. Для заголовков objc / objC++ используйте #import.

Если вы знакомы с C++ и макросами, то

#import "Class.h" 

похоже на

{
#pragma once

#include "class.h"
}

Это означает, что ваш класс будет загружен только один раз при запуске вашего приложения.

Я знаю, что эта ветка устарела ... но в "современное время" ... существует гораздо более совершенная "стратегия включения" через модули clang's @import - это часто упускается из виду ..

Modules improve access to the API of software libraries by replacing the textual preprocessor inclusion model with a more robust, more efficient semantic model. From the user’s perspective, the code looks only slightly different, because one uses an import declaration rather than a #include preprocessor directive:

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

или же

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

However, this module import behaves quite differently from the corresponding #include: when the compiler sees the module import above, it loads a binary representation of the module and makes its API available to the application directly. Preprocessor definitions that precede the import declaration have no impact on the API provided... because the module itself was compiled as a separate, standalone module. Additionally, any linker flags required to use the module will automatically be provided when the module is imported. This semantic import model addresses many of the problems of the preprocessor inclusion model.

Чтобы включить модули, передайте флаг командной строки -fmodules, также известный как CLANG_ENABLE_MODULES, в Xcode- во время компиляции. Как упоминалось выше .. эта стратегия устраняет ЛЮБОЙ и ВСЕ LDFLAGS. Например, вы можете УДАЛИТЬ любые настройки "OTHER_LDFLAGS", а также любые этапы "Связывание" ..

Я считаю, что время компиляции / запуска "кажется" гораздо более быстрым (или, возможно, просто меньше задержек при "связывании"?) .. а также дает прекрасную возможность очистить теперь посторонний файл Project-Prefix.pch, и соответствующие настройки сборки, GCC_INCREASE_PRECOMPILED_HEADER_SHARING, GCC_PRECOMPILE_PREFIX_HEADER, GCC_PREFIX_HEADER и т. д.

Кроме того, хотя это не так хорошо документировано ... Вы можете создавать module.map для своих собственных фреймворков и включать их таким же удобным способом. Вы можете взглянуть на мой репозиторий ObjC-Clang-Modules на github, чтобы увидеть несколько примеров того, как реализовать такие чудеса.

Возможно, у меня была глобальная переменная в одном из моих файлов .h, которая вызвала проблему, и я решил ее, добавив перед ней extern.

#include + guard == #import

#include guard^Wiki - защита от макросов, заголовков или файлов предотвращает двойное включение заголовка preprocessor, что может замедлить время сборки

Следующий шаг

.pch^[About] => @import^[About]

[#import in .h или .m]