Jaka jest różnica między #import i #include w Objective-C?

Jakie są różnice między #import i #include w Objective-C i czy są chwile, w których powinieneś używać jednego nad drugim? Czy ktoś jest przestarzały?

Czytałem następujący samouczek: http://www.otierney.net/objective-c.html#preamble, a jego akapit dotyczący #import i #include wydaje się zaprzeczać samemu lub przynajmniej jest niejasny.

Dyrektywa #import została dodana do Objective-C jako ulepszona wersja #include. Jednak kwestia, czy jest poprawiona, jest nadal kwestią dyskusyjną. #import zapewnia, że ​​plik jest dołączany tylko raz, więc nigdy nie będziesz mieć problemu z rekurencyjnymi włączeniami. Jednak większość porządnych plików nagłówkowych i tak się przed tym chroni, więc nie jest to tak bardzo korzystne.

Zasadniczo to Ty decydujesz, którego chcesz użyć. Staram się #importować nagłówki do rzeczy w Objective-C (takich jak definicje klas i tym podobne) i #include standardowych rzeczy C, których potrzebuję. Na przykład jeden z moich plików źródłowych może wyglądać następująco:

#import <Foundation/Foundation.h>

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

Wydaje się, że istnieje wiele nieporozumień dotyczących preprocesora.

Co robi kompilator, gdy zobaczy #include, że zastępuje ten wiersz zawartością dołączonych plików, bez zadawania pytań.

Więc jeśli masz plik a.hz tą zawartością:

typedef int my_number;

i plik b.cz tą zawartością:

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

plik b.czostanie przetłumaczony przez preprocesora przed kompilacją

typedef int my_number;
typedef int my_number;

co spowoduje błąd kompilatora, ponieważ typ my_numberjest zdefiniowany dwukrotnie. Mimo że definicja jest taka sama, język C nie zezwala na to.

Ponieważ nagłówek jest często używany w więcej niż jednym miejscu, w C. zwykle stosowane są osłony. Wygląda to tak:

 #ifndef _a_h_included_
 #define _a_h_included_

 typedef int my_number;

 #endif

Plik b.cnadal zawierałby całą zawartość nagłówka dwukrotnie po przetworzeniu. Ale druga instancja zostałaby zignorowana, ponieważ makro _a_h_included_zostałoby już zdefiniowane.

Działa to naprawdę dobrze, ale ma dwie wady. Przede wszystkim należy napisać strażników dołączania, a nazwa makra musi być inna w każdym nagłówku. Po drugie, kompilator wciąż musi szukać pliku nagłówka i czytać go tak często, jak jest dołączony.

Objective-C ma #importinstrukcję preprocesora (może być również używana do kodu C i C ++ z niektórymi kompilatorami i opcjami). Robi to prawie tak samo jak #include, ale wewnętrznie zauważa, który plik został już dołączony. #importLinia otrzymuje jedynie przez zawartość pliku o nazwie po raz pierwszy go spotkałem. Za każdym razem jest to po prostu ignorowane.

Zgadzam się z Jasonem.

Zostałem przyłapany na robieniu tego:

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

W przypadku GNU gcc ciągle narzekał, że funkcja time () nie została zdefiniowana.

Więc zmieniłem #import na #include i wszystko poszło dobrze.

Powód:

#Import <sys / time.h>:
    <sys / time.h> obejmuje tylko część <time.h> przy użyciu #defines

Ty #import <time.h>:
    Nie idź. Mimo że tylko część <time.h> została już uwzględniona, jeśli
    chodzi o #import, plik ten jest już całkowicie uwzględniony.

Dolna linia:

Nagłówki C / C ++ tradycyjnie zawierają części innych plików dołączanych.
Dlatego w przypadku nagłówków C / C ++ użyj #include.
W przypadku nagłówków objc / objc ++ użyj #import.

#includedziała podobnie jak C #include.

#importśledzi, które nagłówki zostały już uwzględnione i jest ignorowany, jeśli nagłówek jest importowany więcej niż raz w jednostce kompilacyjnej. To sprawia, że ​​nie trzeba używać osłon nagłówka.

Najważniejsze jest użycie #importw Objective-C i nie martw się, jeśli twoje nagłówki skończą importować coś więcej niż raz.

Wiem, że ten wątek jest stary ... ale w „czasach współczesnych” .. istnieje moduły clanga@import o wiele lepsze niż „strategia” - to często pomijane…

Moduły poprawiają dostęp do interfejsu API bibliotek oprogramowania, zastępując tekstowy model włączenia preprocesora bardziej solidnym, wydajnym modelem semantycznym. Z punktu widzenia użytkownika kod wygląda tylko nieco inaczej, ponieważ używa się deklaracji importu, a nie dyrektywy preprocesora #include:

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

lub

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

Jednak ten import modułu zachowuje się zupełnie inaczej niż odpowiedni #include: gdy kompilator zobaczy powyższy import modułu, ładuje binarną reprezentację modułu i udostępnia bezpośrednio interfejs API aplikacji. Definicje preprocesora poprzedzające deklarację importu nie mają wpływu na udostępniony interfejs API ... ponieważ sam moduł został skompilowany jako osobny, samodzielny moduł. Ponadto wszelkie flagi linkera wymagane do korzystania z modułu będą automatycznie dostarczane po zaimportowaniu modułu. Ten semantyczny model importu rozwiązuje wiele problemów modelu włączenia preprocesora.

Aby włączyć moduły, przekaż flagę wiersza polecenia -fmodulesaka CLANG_ENABLE_MODULESin Xcode- w czasie kompilacji. Jak wspomniano powyżej ... ta strategia eliminuje WSZYSTKIE i WSZYSTKIE LDFLAGS. W tej chwili możesz USUNĄĆ wszelkie ustawienia „OTHER_LDFLAGS”, a także wszelkie fazy „Łączenie”.

Uważam, że czasy kompilacji / uruchamiania „czują się” znacznie szybsze (a może po prostu mniej opóźnień podczas „łączenia”?) .., a także, stanowią doskonałą okazję do wyczyszczenia obcego pliku Project-Prefix.pch, i odpowiadających ustawień budować GCC_INCREASE_PRECOMPILED_HEADER_SHARING, GCC_PRECOMPILE_PREFIX_HEADERi GCC_PREFIX_HEADERitp

Ponadto, choć nie jest to dobrze udokumentowane… Możesz tworzyć module.mapwłasne ramy dla własnych ram i włączać je w ten sam wygodny sposób. Możesz zapoznać się z moim repozytorium github z modułów ObjC-Clang-Modules, aby zobaczyć przykłady implementacji takich cudów.

Jeśli znasz C ++ i makra, to

#import "Class.h" 

jest podobne do

{
#pragma once

#include "class.h"
}

co oznacza, że ​​Twoja klasa zostanie załadowana tylko raz po uruchomieniu aplikacji.

Być może miałem zmienną globalną w jednym z moich .hplików, która była przyczyną problemu, i rozwiązałem ją, dodając externprzed nią.

JEŚLI # dołączasz plik dwa razy do plików .h, niż kompilator da błąd. Ale jeśli #importujesz plik więcej niż raz, kompilator go zignoruje.

#includekiedyś przenosił „rzeczy” z innego pliku do tego, w którym #includejest używany. Np .:

w pliku: main.cpp

#include "otherfile.h"

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

Zabezpieczenie nagłówka jest używane na górze każdego pliku nagłówka (* .h), aby zapobiec dołączeniu tego samego pliku więcej niż jeden raz (jeśli tak się stanie, wystąpią błędy kompilacji).

w pliku: otherfile.h

#ifndef OTHERFILE
#define OTHERFILE

// declare functions, classes or objects here

#endif

nawet jeśli wpiszesz #include„otherfile.h” n w swoim kodzie, to w nim nie zostanie ponownie zapisane.

#include + guard == #import

#include guard^Wiki - ochrona makr, ochrona nagłówka lub ochrona plików zapobiega podwójnemu włączeniu nagłówka,preprocessorco może spowolnić czas kompilacji

Następnym krokiem jest

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

[#import w .hlub .m]