2009-04-22 6 views
9

Это может показаться действительно глупым вопросом, но какова стоимость включения (фактически, вызывающего #import) заголовочного файла в Objective-C? Я устал постоянно включать одни и те же заголовки в разных местах, поэтому я решил просто создать файл GlobalReferences.h, который содержит несколько заголовков с общими ссылками.Стоимость включения файлов заголовка в Objective-C

Есть ли заметная стоимость для включения ссылок на другие файлы, если они даже не используются? Моя кишка говорит мне «нет», поскольку кажется, что компоновщик только что узнал о других файлах при использовании #import, но я не был уверен, что для разработки iPhone необходимо учитывать особые соображения, что касается моего проекта. Есть предположения?

ответ

7

Линкер ничего не знает о #import ed файлах. На самом деле компилятор Objective-C ничего не знает о них, они предварительно обрабатываются препроцессором. Препроцессор эффективно вставляет содержимое заголовков в то место, которое вы включили в исходный файл. Фактический компилятор Objective-C должен будет обработать дополнительные прототипы функций и определения интерфейса класса, даже если они не используются. Хотя это обычно не является длительной задачей, это может увеличить время компиляции. Результирующий размер и производительность вашего приложения не должны оставаться неизменными.

Чтобы увидеть, что исходный код сырым выглядит (включая все файлы заголовков и расширенные макросы и т.д.):

gcc -E your-source-file.m 
+0

Спасибо, что расчистили это. – LucasTizma

2

Самый большой недостаток будет в разы компиляции. Если все ваши заголовки импортированы в каждый исходный файл, то проект всего придется перестраивать каждый раз, когда вы вносите изменения в файл заголовка.

3

Импортирование/включение большего количества файлов заголовков, чем вам потребуется, увеличит время компиляции. Вы можете облегчить часть этой боли с помощью pre-compiled headers.

0

идти вперед и делать это. Если заголовки, которые вы включаете, массивны, и вы не используете предварительно скомпилированные заголовки, вы не должны видеть никакой разницы. Как говорили другие, #import - это препроцессорная директива. Это не имеет последствий во время выполнения и во многих случаях не имеет значительного времени компиляции.

+0

Спасибо, всем, за разъяснения по этой проблеме. – LucasTizma

1

Какова стоимость включения (фактически, вызова #import) заголовочного файла в Objective-C?

Компилятор может закончиться без необходимости читать эти файлы. После #import ed дополнительные файлы должны быть проанализированы, скомпилированы и т. Д. Для каждого перевода (например, файл .m), это видно в: время сборки и ссылок намного дольше. 10 раз дольше не удивительно.

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

Как правило, это очень плохой подход. Общая проблема заключается в том, что всякий раз, когда какой-либо из файлов, включенных в GlobalReferences.h, изменяется, весь проект и все взаимозависимые зависимости нужно перестраивать, перенаправлять и т. Д.

Мое предпочтение состоит в том, чтобы разделить программы на небольшие библиотеки или пакеты, где существует эта взаимозависимость (например, StoreKit.framework - это небольшой пакет/библиотека), но набивка этих библиотек/фреймворков/пакетов в заголовках ничего не решает. Кроме того, форвардные декларации и сохранение ваших данных в продолжении класса или @implementation могут значительно уменьшить зависимости (потому что вы можете локализовать включение библиотеки/заголовка только в необходимые переводы).

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

Есть ли какая-то значительная цена на включение ссылок на другие файлы, если они еще не используются?

Абсолютно. Чем больше ваши проекты растут, тем хуже становится ленивое включение. Несколько ленивых включений в большой проект могут добавить десятки или сотни тысяч строк в большинство ваших скомпилированных файлов и могут вызвать частое перекомпиляцию многих источников. Это добавляет значительную сложность в процесс сборки - требования к процессору идут вверх, использование ОЗУ идет вверх, дисковый IO идет вверх ... и снова это становится более серьезной проблемой по мере увеличения сложности ваших кодовых баз/проектов.