#include увеличивает использование оперативной памяти?

Если я включу больше заголовочных файлов, увеличится ли требуемый размер ОЗУ? Например, понадобится ли мне больше оперативной памяти, если я #include <stdio.h> и #include <string.h>?

Я пишу встроенное системное программное обеспечение с компилятором CNU C, поэтому я хочу максимально сократить объем оперативной памяти.


person eepty    schedule 28.05.2012    source источник
comment
Увеличить объем ОЗУ, необходимый для компилируемой программы, или увеличить объем ОЗУ, необходимый для самого компилятора?   -  person jamesdlin    schedule 28.05.2012
comment
Я имею в виду размер ОЗУ, необходимый для программы, которую я компилирую, у меня только 64 КБ внутренней ОЗУ в микроконтроллере, и я всегда беспокоюсь, что ему не хватает ОЗУ, потому что его очень сложно отлаживать...   -  person eepty    schedule 06.06.2012
comment
Ничего себе, во-первых, я думаю, что мой вопрос кажется глупым и слишком тривиальным, я задавался вопросом, стоит ли его задавать .... но теперь я думаю, что его стоит задать, так как так много разных ответов и комментариев ...   -  person eepty    schedule 06.06.2012


Ответы (6)


Ответ на то, что вы действительно хотите спросить, вероятно, «нет», по крайней мере, когда вы говорите о заголовках стандартной библиотеки. Их включение не повлияет на размер исполняемого файла или занимаемую память. Тем не менее, я не могу удержаться от противоположного ответа:

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

// foo.c
int bigarray[1000];

и

// bar.c
#include "foo.c"
int main(int argc, char**argv()) {
return 0;
}

это допустимый код, и bar.c будет хорошо компилироваться, но мой объем памяти может быть на 4 КБ больше из-за массива в foo.c (если компилятор не оптимизирует его).

person Enno    schedule 28.05.2012
comment
Этот код не включает файл заголовка. Любой, кто пытается включить файлы .c, должен винить только себя. Кроме того, очень маловероятно, что компилятор включит bigarray в исполняемый файл. - person Lundin; 28.05.2012
comment
Заголовочные файлы являются соглашением в C. Компилятору все равно, как вы называете файл или что вы в нем пишете. Кроме того, я сказал, что пытался возразить :-) Что касается исключения включения bigarray в исполняемый файл, попробуйте следующее: gcc -o bar bar.c && nm bar | grep бимассив - person Enno; 28.05.2012
comment
Неважно, что принимает компилятор, потому что ОП специально спрашивал, что произойдет, если они включат файлы заголовков, а ваш код этого не делает, поэтому он не отвечает на вопрос. Запуск компилятора без включенных оптимизаций также не имеет значения. - person Lundin; 28.05.2012
comment
Переименуйте foo.c в foo.h, а затем измените #include \foo.c\ на #include \foo.h\. :П - person imallett; 25.08.2012

Нет, включаемые файлы предназначены для компилятора; они вообще не влияют на размер генерируемого кода.

person Francis Upton IV    schedule 28.05.2012

Включение заголовков эффективно только во время компиляции. Они используются, чтобы сообщить компилятору, где он может найти нужные ему реализации.

Скомпилированный исполняемый файл не содержит эту информацию, поэтому на него не влияет количество включений.

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

person Samy Arous    schedule 28.05.2012

Нет. Включаемые файлы — это не функции, это ссылки на системные функции (по крайней мере, на те, которые поставляются с вашим компилятором). Если вы хотите убедиться сами, перейдите в каталог include вашего компилятора и откройте файлы в текстовом редакторе (НО НИКОГДА НЕ ИЗМЕНЯЙТЕ ИХ). Они такие же, как и любые другие .h, которые вы пишете; они не определяют никаких функций.

Компилятор увидит, что имя функции (например, printf) допустимо, и скомпилирует его в объектный файл. Компоновщик позаботится о том, чтобы превратить это имя в допустимый системный вызов.

person Cole Johnson    schedule 28.05.2012
comment
Я вижу, вы используете слово ядро. Я не думаю, что это означает то, что вы думаете. - person Enno; 28.05.2012
comment
Задавался тем же вопросом :) Я думаю, что он имел в виду ядро. Или может я ошибаюсь. Системные функции были бы неправильными, так как некоторые из них указывают на функции более высокого уровня. - person Samy Arous; 28.05.2012
comment
@Энно, это просто в моей операционной системе, которую я написал, и написанном мной скрипте компоновщика, это вызовы ядра. - person Cole Johnson; 28.05.2012

да, я могу увеличить размер двоичного файла, а затем увеличить размер ОЗУ. Это происходит двумя способами: 1. В головном файле есть определение глобальных/статических переменных. 2. В головном файле есть функция, даже если она не используется для текущего файла. Но компилятор может по-прежнему хранить их в финальном бинарном виде.

Я говорю «может увеличиться», потому что, если компилятор достаточно умен, я могу включить только данные, необходимые для двоичного файла, но отбросить другие.

для другого содержимого, возможно, в головном файле, например, объявление переменных, typedef и т. д., они не будут увеличивать ОЗУ, потому что это требуется только во время компиляции, а не во время выполнения.

person RolandXu    schedule 28.05.2012
comment
Компилятор, скорее всего, сохранит их в конечном двоичном файле только в том случае, если эти глобальные/статические переменные действительно используются программой. Кроме того, файлы заголовков стандартных библиотек обычно пишутся опытными профессиональными программистами, поэтому вы не найдете в заголовках никаких глобальных/статических переменных. - person Lundin; 28.05.2012
comment
@Lundin Я говорю о вероятности. Я не писатель библиотеки, поэтому я не знаю, как они пишут. Это не так, поэтому вы не знаете эфира. - person RolandXu; 28.05.2012
comment
Эээ... на самом деле знаю. Большинство компиляторов держат свои заголовки полностью открытыми. - person Lundin; 29.05.2012

Да, но только немного... но это увеличивает загрузку процессора. вы можете проверить это в диспетчере задач Windows....

person Devang Sinha aka W4R1OCK    schedule 28.05.2012
comment
Я думаю, совершенно очевидно, что OP означает потребление оперативной памяти исполняемым файлом, а не компилятором. Кроме того, в вопросе нет ничего, указывающего на то, что код скомпилирован в MS Windows. - person Lundin; 28.05.2012