Правлю чужой код. AVR-GCC, Atmega128
При компиляции выдает море warning-ов на memset, memcpy и.т.п.
Проблему ли в том что нет #include "string.h".

Например:
../utils.c:47: warning: implicit declaration of function 'memset'
../utils.c:47: warning: incompatible implicit declaration of built-in function 'memset'


Но! Стало любопытно, ведь устройства с прошивкой продаются и вроде работают)
Почему, что сотворил компилятор?

При известных на этапе компиляции параметрах он генерит встроенные оптимальные (под конкретные параметры) тела функций вместо вызова библиотек. В противном случае споткнулся бы линкер.

Хм т.е. все сделано правильно??
И #include "string.h" не стоит добавлять?

Не каждого, переходящего на красный свет сбивает машина. Стоит всегда переходить на красный свет?

выходит, этот трюк можно использовать для снижения объема кода(если кроме простых memset, memcpy и т д, функций не зовешь)? Не включаешь #include "string.h" и библиотека не занимает места?

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

Возможно я неясно выразился: Включать string.h, конечно, нужно. Просто в некоторых тривиальных случаях компилятор может вместо вызова библиотечной функции вставить прямо в код ее оптимизированную под конкретный случай версию. А если случай нетривиальный (один из параметров - переменная и ее значение неизвестно на этапе компиляции) он вызовет библиотечную функцию.

Советую ознакомиться с
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...%86%D0%B8%D0%B8

А вообще - ИМХО это бадстайл (функции без прототипа)


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

Я вставляю реализацию функций static inline.
Что имеете против?

функция != переменная

Я извиняюсь, но параметры - практически всегда переменные, но это не препятствие для встраивания тела функции в код. Может memset не самый удачный пример из-за того, что память обычно заполняют какой-то константой, но вот функцию abs() глупо вызывать, передавая ей в качестве параметра константу, согласись. Тем не менее она ведет себя так же - компилятор о ней занет даже без прототипа и встраивает ее тело прямо в код.



Спасибо, я уже закончил детский сад


От деклараций (declaration) переменных ни код, ни озу не увеличится. он может увеличиться от определений (definition) переменных или функций. Но это, действительно могут делать только очень талантливые программисты, потому что стоит этот h-файл включить в два c-файла, как линкер выдаст ошибку о том, что в программе имеются несколько переменных с одинаковым именем.


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

ЗЫ. static имеет много значений в C в зависимости от контекста, а что он означает применительно к функции? Я полагаю имеется в виду pure-С?

Если они объявлены как static, то промолчит, проглотит и не поперхнется.
static применительно к функции? - ограничивает ее область видимости вроде как.

static - как по мне : ограничение видимости в пределах файла

Это для переменных. Неужели по отношению к функциям это имеет такой же смысл?

Пример. Поддержка 7-сегментного индикатора. Кроме знакогенератора и определения собсна цифр как совокупности сегментов там ничего нет. Предлагаете знакогенератор определять где-то в другом месте, а в хедере описывать только как extern?

А вы попробуйте!

Именно такой.
Если вынести функцию в h-файл без префикса static и подключить к нескольким с-файлам, линкер будет вопить о множественном определении.

Я предлагаю определять массив с цифрами в той функции, которая будет ими пользоваться. В памяти программ, естественно. Как-то так:

При чем тут h-файл - хз.

для даного тривиального случая да
для большого массива который используется многими функциями в разных с-файлах не получиться - памяти программ может не хватить, ИМХО

Отнюдь! static для переменных кроме ограничения области видимости это еще и резервирование памяти (вместо размещения на стеке или в регистрах) и группировка переменных в Z-область данных, которая обнуляется при старте программы до вызова main.

Собственно, если Вы потрудитесь переключить вид темы на древовидный. то увидите, что мой ответ мало относится к дате выпускного вашего детсада
Он был адресован топикстартеру

А для большого массива который используется многими функциями в разных с-файлах определять (define) массив в h-файле тем более нельзя - тогда будут либо проблемы линкера, либо (если его объявить static) в каждом C-файле будет содержаться отдельный экземпляр этого массива, что увеличит размер памяти. И каждая функция будет работать со своим массивом. Если он только для чтения, то ты этого не заметишь, если же это массив данных (в ОЗУ), то программа работать не будет.

ЗЫ. только сейчас заметил: "памяти программ может не хватить" Ты знаешь контроллеры, в которых память программ меньше, чем память данных? И поэтому такие массивы ты хранишь в ОЗУ? А позволь спросить, как ты их при этом инициализируешь? Ведь инициализировать их можно только из памяти программ, а если они там поместились, зачем из переписывать в ОЗУ?

А Вы знаете?


вы будете иметь доступ к массиву Freq из другой функции рассположеной в этом же файле?

gcc когда встречает использование функции, которая не была объявлена расценивает это как объявление функции (о чём и говорит варнинг "implicit declaration of function 'memset'")
когда на стадии линковки выясняется, что фактическое определение функции не совпадает с "implicit declaration", но количество параметров и их размер (но не тип) совпадают, то компилятор ТАКИ линкует код (и снова делает варнинг). Это оказывается работоспособным. Такое поведение НИКАК не связано со способностью компилятора делать оптимизации. невключение заголовочников не уменьшит код ни на грамм.

Нет, поэтому и помещаю константные массивы в память программ, а не данных

Этот массив другим функциям не нужен.

Ну а если будет нужен, то Вы займётесь бездумным тиражированием и места ФЛЭШ может не хватить. Об этом я хотел и сказать. Особенно если массив большой а функций его использующих - много.

Нет, это вы займетесь тиражированием. Если массив объявить static и поместить в h-файл, то в каждом c-файле будет экземпляр этого массива! Чтобы он был один, он должен находиться в одном c-файле (без static), а в остальных c-файлах (или в h-файле который в них включаются) он должен быть объявлен как extern. Я не знаю, ну это же азы.

Спасибо, не знал.

Это заблуждение.
Если статическая переменная не используется в коде, то она выкидывается оптимизатором при уровне оптимизации большем чем -00.
пример:



смотрим что попало в бинарь:


теперь включаем минимальную оптимизацию:


смотрим что попало в бинарь:


как видим статическая переменная не попала бинарь так как не используется!

Речь идет о том, что она используется, просто вы не прочитали эту ветку с начала.
Если бы она использовалась в одном файле, то можно было определить ее в этом же файле и вопросов бы не возникало. Если же она требуется в нескольких, то некоторые товарищи считают удобным определить (define) ее в h-файле, а чтобы линкер не ругался на то, что она определена в нескольких C-файлах (если этот h-файл в них включен), предлагают объявить ее static. Линкер ругаться перестает, но при этом создает по экземпляру на каждый C-файл в котором она используется. Что, в общем-то естественно. Если это какой-то константный массив (например, таблица 7-сегментного индикатора) то никаких проблем кроме увеличения памяти не произойдет. Если же это именно переменная в ОЗУ, то работающие с ней функции (разумеется если они из разных файлов) будут фактически работать с разными переменными и одна из них не увидит что записала другая.

У меня почему-то линкер не ругался на глобальные переменные (не static), определённые (не объявленные!) в одном заголовочнике, на который куча файлов ссылается. (Да, быдлокод - это я сейчас понимаю, но переделывать уже поздно - "работает - не трогай".)

А вот на попытку сделать глобальной константу (const) - таки ругается. (Это я тогда еще не знал о progmem).

С или С++?
И примерчик приведите.

Чистый С. gcc - WinAVR 20050214.

файл global.h:


файл check.с:


файл ins.с:


файл outs.с:


Вот такой изврат...
И ведь работает... Только грабли с непрозрачностью потоков данных - во весь рост. Но это уже другая тема.

Странно, что работает.
Грамотнее было бы U16 d_status; определить в файле global.c, а в файле global.h обьявить как extern U16 d_status;
И никакого изврата.

Да вот сам удивляюсь, читая эту ветку.
Что грамотнее - знаю. Говорю же - быдлокод. Вам год версии WinAVR ничего не говорит? Это пять лет назад было - я не знал ни о extern, ни о progmem, только начинал кодить на C, до того на асме для 51-х писал, да на всяких дельфях и фокспро.

Ты думаешь что в той версии было можно а сейчас нет? А поскольку сейчас той версии ни у кого нет, то придется верить на слово? Я в это не верю - если одна переменная будет объявлена в нескольких объектных файлах, то линкер не может не ругаться. Просто потому, что он не сможет эти переменные разместить. Может твой h-файл включался только в один C-файл и тогда это прокатывало.

Возможно та версия WinAVR не применяла раздельную компиляцию файлов. Тогда все понятно. На самом деле хедер был включен лишь один раз. Остальные два блокировались препроцессором (#ifndef GLOBAL_H ... #endif).

То есть в C-файл включались не только хедеры, но и остальные C-файлы? Неужели WinAVR был таким примитивным?

Не знаю, я только предположение высказал

А полностью абзац прочитать? Я имел в виду, что это было давно, и в таком стиле я уже не пишу.


А я не верю, что ни у кого нет.
И можно проверить в более свежей версии.
Сейчас вот накидал тестовый проектик в 20090313 - работает, ни одного варнинга.

Прикладываю проект вместе с lst и map, а также скриншоты прогона в эмуляторе.
Нажмите для просмотра прикрепленного файла
Data: 1 bytes (0.1% Full)
(.data + .bss + .noinit)
Build succeeded with 0 Warnings...

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Забавно. Те же файлы подсунутые в Visual Studio 2008 выдали ошибку:

1>module.obj : error LNK2005: "char global_var" (?global_var@@3DA) already defined in test.obj
1>C:\Users\SWW\Documents\Visual Studio 2008\Projects\test\Debug\test.exe : fatal error LNK1169: one or more multiply defined symbols found

И еще кто-то говорит о стандартах и переносимости... Интересно, а что скажет IAR, кто-нибудь проверит?

А предупреждения включены? Их вывод лучше в makefile задавать.
IMHO: лучше включить все, ну, кроме некоторых , чтобы потом не было грусно при отладке.

Предупреждения - по умолчанию. Этого недостаточно?
И ведь дело не в предупреждениях - по прогону явно же видно, что отовсюду ссылка идет на одну и ту же переменную, да и memory usage при компиляции отчиталось - "1 bytes". (если сделать переменную static - получаем "Data: 2 bytes" ).

Интересно бы проверить в "большом" gcc.

Кстати, вот если в global.h вставить

- вываливается ошибка "multiple definition of `glob_const'". Соответственно "Build failed with 1 errors and 0 warnings..."