Как лучше писать Опции

[npopok]

Keil mVision.Соответственно, есть куча разных функций.Одни для одного,другие для другого, где то они пересекаюся и не редко.В общем, как обычно.Вот вопрос-стоит ли собирать их в разные си файлы и делать кучу extern-ов, или лучше все-таки без особой необходимости этого не делать.Может, надо искать золотую середину?Есть ли какие-нибудь критерии,кроме здравого смысла? На что это влияет?Спасибо

[MrYuran]

Обычно всегда стараюсь чётко разделить программу на модули, как можно более автономные. Функции, описанные в модулях, выносим в h-файл, и в других модулях его подключаем. Всё как обычно. Переменные тоже желательно разделить, для внутримодульного употребления - static.
Да это и не только для АРМ и Кейла, а вообще нормальный стиль программирования.
Потом я беру, к примеру, модуль Indicator.c, перетаскиваю в новый проект и он без единой настройки сразу работает.
А чтобы не было "кучи extern-ов", нужно в модуле группировать данные и функции для работы с этими данными. Чтобы не было глобальных пересечений и взаимосвязей.

[sergeeff]

Мы обычно поступаем так. Для примера. Одна пара С и Н файлов - все функции для генерации одного типа штрих кода. В этом файле не обязательно все функции нужны кому-то вовне, они, так сказать, "для внутреннего использования". Такие функции объявляем как static, а прототип такой функции помещаем в начало С-файла, а на в Н-файл. В Н-файл - объявления (прототипы) всех "глобальных" функций. Для совместимости с С++ лучше их сразу обрамить описаниями вида:

#ifdef __cplusplus
extern "C" {
#endif
...
...


#ifdef __cplusplus
}
#endif // __cplusplus


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

Чтобы в будущем не путаться где и что, надо продумать систему именования файлов и библиотек.

[npopok]

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

[MrYuran]

Такой вопрос-если я забью на модульность и совместимость, получу ли я прирост скорости или там свободного места?

Встречный вопрос: а засчёт чего?
Компилятор транслирует исходники функций в объектный код, линкер собирает из объектов файл прошивки. По большому счёту, им без разницы, в одном файле находятся функции или в 10. (20,50).
Скорость и свободное место - понятия взаимоисключающие.
Нужна скорость - inline и unrolling, соответственно теряем место.
Не хватает места - обратная ситуация, приходится жертвовать скоростью.

[Kaplinsky]

Советую почитать книгу
"Анализ программного кода на примере проэктов Open Source"
автор Диомидис Спинеллис.
http://oz.by/books/more1011402.html

[etoja]

Начни с этого:

Прикрепленные файлы

 CTest.rar ( 31.32 килобайт ) Кол-во скачиваний: 96

 

[npopok]

Последнее ,конечно, полезно, но вообще не в тему

[Сергей Борщ]

Встречный вопрос: а засчёт чего?

Например, компилятор может самостоятельно встроить функции, используемые только один раз и объявленные как static. Экономия на командах вызова, передаче параметров, прологе/эпилоге.
Некторые функции содержат кода меньше, чем накладные расходы на ее вызов. Или функции-обертки, которые при встраивании вообще не генерят кода. Безусловное встраивание таких функций дает выигрыш и в объеме и в скорости. Если функция не static и тело ее в другом файле - компилятор не сможет ее встроить. Таким образом, некоторые функции модуля целесообразно выносить из .c в .h, добавляя к ним квалификатор static. Они могут потянуть за собой другие. Если же функция большая и используется дважды - получим обратный эффект. Такая оптимизация в любом случае происходит при помощи программиста, и порой в угоду читабельности и модифицируемости кода стоит некторые участки оставить неоптимальными. В противном случае придем у ручной правке ассемблерного кода после компилятора.

[Duplex]

Советую почитать книгу

Цена: 29 826 руб.


А я бы не советовал. За такие деньги? Нифига себе - оупен сорс!

[defunct]

Компилятор транслирует исходники функций в объектный код, линкер собирает из объектов файл прошивки. По большому счёту, им без разницы, в одном файле находятся функции или в 10. (20,50).

Ну разница все-таки есть.
Если все в одном файле, и функции объявлены как static. Компилятор может сделать более эффективный код (например повставлять инлайнов там где это не указано явно, повыбрасывать неиспользуемые функции, заменить "дальний" вызов на "ближний" для процессоров где это актуально и .т.п.). С т.з. оптимизации компилятору лучше сразу видеть весь код в одном файле, потому что линкер ничего оптимизировать не будет.

Только читаемость когда "все в одном" будет никакой.

[MrYuran]

Цена: 29 826 руб.

Я уже наверно рассказывал байку.
Едут мужики в Белоруссию в командировку.
На поезде.
Проводница заглядывает в купе: - чай будете?
- Ну да...
Взяли по чашечке.
- С вас 120 рублей.

Потом дошло, что беларусских.
</offtop>
2 Сергей Борщ :
я обычно сам ручками пишу __inline__, не надеясь на компилятор

[defunct]

Нужна скорость - inline и unrolling, соответственно теряем место.

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

В контексте ARM, если inline выполняется условно, то можно получить участок кода из условно выполняющихся команд. Этот участок (например десяток линейных команд) будет подгружаться и выполняться всегда, но ничего не будет делать когда условие ложно. В итоге быстродействие - страдает.

[scifi]

Обычно всегда стараюсь чётко разделить программу на модули, как можно более автономные. Функции, описанные в модулях, выносим в h-файл, и в других модулях его подключаем. Всё как обычно. Переменные тоже желательно разделить, для внутримодульного употребления - static.

+1. Сам к этому пришёл, основываясь на горьком опыте. Программы стали значительно более читаемыми. И больше не надо держать в голове всё это хитросплетение из глобальных переменных и функций.
Ещё одно правило - комментарий к каждой функции.

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

Забивание на модульность приведёт к менее читаемой программе, а в ней потери скорости/памяти возникнут сами собой из-за бардака. И вообще, начинать оптимизировать надо только после того, как необходимость оптимизации была доказана измерениями. Иначе это пустая трата времени. Конечно, это не отменяет того, что выбираемые решения и алгоритмы должны изначально быть реалистичными (к примеру, таблица синусов на 100 кБайт не влезет в МК с 32 кБайтами).

[Duplex]

Потом дошло, что беларусских.

Доллары тоже разных стран бывают, но люди сразу их обозначают.
Доллар США - пишут USD.
Тут тоже могли бы писать - белорубль.