От няколко месеца пробивам на С фронта, и искам да събера пъзела от всичките му особености. Докато пишех малки програмки за мигане на светодиоди нямах нужда и от знанията за хедър и сорс файловете в един проект. Но започва да ми става тясно и не намирам обяснението/документа(цията) с което да си обясня организацията на всички файлове в един проект. В момента ползвам хедър файлове, но проектите ми са някак объркани, смесени са код , променливи ползвани от няколко модула, различни дефиниции също ползвани от няколко модула в различни файлове. Т,е, ако искам даден проект да го ползвам в някой друг объркаността с файловете само излишно ще губи време. Опитах се четейки доковете за езика С да си изясня липсващите ми знания, но нещата не ми стават съвсем ясни.
Съществува ли подобна документация и как да я търся?

Сигурно има и такава документация , при мен например повечето неща се получиха с практиката, така че няма за какво да се притесняваш, че има нещо объркано в програмите ти.

Има правила, които ако се спазват правят живота по-лесен. Например, в header файловете не се дефинират променливи и функции, дефинират се само макроси, декларират се типове на променливи, функции, структури и т.н. Тънката разлика между декларация/дефиниция е, че при декларирането се прави описание на прототип, но не се заема памет, докато дефинирането е вече фактическото упоменаване за съществуването на дадена променлива/функция, т.е. дава се име на функцията/променливата, генерира се код, заема се памет и т.н.

Още по време на писане на програмата трябва да се стремиш да организараш файловете на проекта като самостоятелни единици, примерно декларациите на функции/променливи свързани в АЦП-то слагай в adc.h, дефинициите на същите в adc.c, UART функции/променливи в uart файловете и т.н. Променливи, които ще се използват в повече от един Ц файл, декларирай като extern в съответните header файлове, това ти спестява труда да пишеш всеки път в съответния Ц файл повторни extern декларации, просто правиш include на header файла. Променливи, макроси свързани с конкретната платформа в отделен файл/файлове, примерно често използвано име от мен е system, дори да речем fuses на едни пиклювци ги слагам в отделен файл fuses.h. Ако разбиеш проекта на достатъчно малки съставни единици, кода става гъвкав и може да се използва лесно навсякъде ( ако го документираш добре ). За тази цел се правят и библиотеки с код, чиято цел е добре работещ и познат код да не се компилира всеки път, ами да го има наготово в компилиран вид, или готов за свързване от линкера.

Навремето като поучително четиво на тази тематика ми послужиха include и source файловете на Borland C++ 2.0,3.1 и Visual C++ ( коя вересия не помня вече ), както и примерните проекти.

За момента знанията си ги попълвам само от документацията по компилаторите за АВР и Пик, но ми се струват недотам обяснени в дълбочина, а повечето са повърхностно споменати. Опитах се да намеря по-големи примерни проекти, но не намерих такива, за да не се лутам и да убивам поредния ден в ровене питам тук.

От това което писа Пирев, ще потърся това борланд С, мисля че го имам някъде архив досовското, но не се бях сещал скоро за него

При PICC проблеми с видимостта на дефиниции от главния файл, от инклуднатите сорс файлове за отделни модули няма, но там стигнах до варианта да изклудвам сорс а не хедър файл, и компилатора е само за начинаещи.
При AVR-GCC нещата някак се закрепиха, за момента се държи прилично и изглежда по-добре отколкото при C30-GCC, доста неща ми се струват изкривени или липсващи. Предполагах че ще има разлики между различните портове на GCC, но нещата не са такива каквито ги предполагам, а са по зле, дано аз да греша .И един пресен проблем относно видимостта на дефиниция: в главния сорс файл дефинирам: #define FREQUENCY 1000000 примерно. След тази дефиниция поставям хедър файлове които съм си писал за различни модули и ползват FREQUENCY, но компилатора извежда съобщение за грешка в сорс файловете ползващи FREQUENCY. Сложих тази дефиниция единствена в един хедър файл и този файл го инклудвам във всеки файл ползващ FREQUENCY. За момента това ми се струва странно да е единственото възможно решение...

Искаш да кажеш, че FREQUENCY не се вижда във включените след нейната дефиниция header файлове, нали ? Защото ако не се вижда в останалите сорс файлове ( освен ако не ги използваш като header файл ) е нормално. Струва ми се странно да не се вижда във включените след нея header файлове, include директивата просто замества реда #include с кода на header файла, след което се компилира така получения разширен C файл.

По принцип всеки C компилатор си е малко бам-башка за себе си, уж всички спазват стандарта, ама го спазват на хартия. Примерно MCC18, ако в дефинициите на макроси използвам цели числа в изразите, дава много странни резултати, затова навсякъде използвам float числа, след което ги стеснявам до integer. Още една особеност на MCC18 е, че когато събира две uint8 числа, дори приемната клетка да е uint16, той изрязва резултата до 8-бита. Тази "особеност" се включва/изключва с опция на компилатора и тогава смята правилно ( както и трябва да бъде според ANSI стандарта )

Да уточня след FREQUENCY поставям хедър файлове, които представят функции от сорс файлове, които функции ползват FREQUENCY. Не знам правилния начин все още, което и иницира тази тема.


Това за макросите и целите числа които ти заменяш със float, ми е много странно, не ползвам посочения компилатор и не съм се набивал на подобен проблем, но ще го имам наум. А относно присъединяването на 8-битова аритметика към по-голям тип, вече му брах ядовете и си каствам операндите в операциите.

Организацията на файловете в един проект няма отношение към C-стандарта, а е до голяма степен решение на разработчика или на фирмата, за която той работи. Това, което обикновено се поставя в хедерите, е:
- константи и макроси, които са свързани с едноименния C-файл и трябва да са видими за другите сорсове
- дефиниции на глобални променливи, които трябва да са видими за другите файлове
- прототипи на функции, ползвани от други сорсове от проекта
Дефинициите на специфични типове (typedef) и структури обикновено се обособяват в самосточтелен файл, общ за проекта.
Има един master хедър файл, който съдържа #include с всички останали хедъри, и той се включва към всеки сорс на проекта.

Всичко по-горе изложено е само един примерен план. Възможни са и други организации.
По-важното е като се установи една система тя да се спазва стриктно.

Точно обратното е . Ако нямаше отношение към C-стандарта, нямаше да има header файлове с константи, макроси и т.н. Щеше да ги праскаме в C сорсовете, и след това във всички останали C сорсове да ги декларираме допълнително, с една дума става манджа с гродзе. Точно самият език ни подсказва как да си организирваме файловете в проектите, така че да са удобни за употреба в други проекти.

Той точно C-стандарта е толкова хлабав, че дори и най-безобразно написаната програма се вписва в него .
Та е станало нужда да измислят MISRA, че и MISRA 2008 и още неизброимо количество фирмени стандарти за писане на код.

Средно за колко време сто маймуни със сто пищещи машини, всяка правеща по средно сто знака в минута ще напишат "Война и мир"?

Война и мир казваш....
Същото, пак с маймуни, само че текст "To be or not to be" беше за един статистически тест....
и го беше писал некъф академичен чичо... обяснявайки (мъчейки се да обясни) някои ентропийни процеси
но както знаем... много важно е началното условие -> бройката маймуни крайна ли е или безкрайна(ограничени множества или безкрайни)

но това е доста извън темата....
пък и е суха материя... и предполага обсъждане на по халба (множество халби) бира

никъде в C/C++ не е задължително да ползваш хедър файлове, можеш да нацвъкаш всичко в един файл - твоя воля !

органицията на проектите е въпрос на опит/култура/знание на пишещия/те.

някои среди на практика стимулират начина на организация (към по-добрия начин), но ако пише "маймуна" - резултата ще е маймунски !

А после някоИ си мислят, че казармата е останала в миналото...уви.
Сипвайте, форумът(маймуните) носят, Колеги!