Witam szanownych kolegów.
Mam prośbę o wyjaśnienie w kwestii sposobu dołączania plików nagłówkowych. Nauczyłem się już (przynajmniej tak sądzę) dzielić projekt na kilka części. Projekty kompilują się i działają
tak, jak był tylko jeden długi plik, ale jednej rzeczy do końca nie rozumiem. Często spotykam się na forum ze stwierdzeniem "dołączyłem pliki nagłówkowe we właściwej kolejności itd...".
No właśnie, jaka jest ta właściwa kolejność. Załóżmy, że mamy coś takiego:




I teraz "includy"

Ja bym np. załączył w takiej kolejności:



Sugeruję się kolejnością funkcji napisanych wyżej, ale czy to tak ma być i czy faktycznie ma to znaczenie ?.

Nadmienię, że jak kolejność była przypadkowa (nie pamiętam już, jaka), to pokazały się błędy i musiałem dodać:



Wówczas błędy znikały. I jeszcze czy nazwy plików w " " musza być na samym dole pod plikami w < >, czy nie.

Proszę o konkretne odpowiedzi w celu rozwiania wszelkich wątpliwości. Z góry dziękuję za pomoc.

avr/io.h jest jednym z obowiązkowych inkludów - on przekierowuje już na konkretny plik np iom32.h itp.

Kolejność jest dowolna, ogolnie przyjęta zasada, że najpierw dajemy inkludy systemowe czyli te <>, potem " " czyli inkludy własnych bibliotek.

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Oglądałeś poradniki Mirka o podziale plików i jak działa kompilator?

Dziękuję za pomoc. Tych akurat poradników nie oglądałem, tak że dziękuję za sugestię. Na pewno skorzystam. Jeśli nie ma znaczenia kolejność plików, to zastanawia mnie tylko fakt, czemu
po zmianie kolejności wyskoczyły alerty, ale może to był "czysty przypadek". Chociaż w komputerze raczej nie powinno być przypadków, a wszystko sprowadza się do tego, co my robimy .
Zabieram się za wyszukiwanie poradników. Pozdrowionka.

PS.

A tak na marginesie, to czy jest możliwość poprawienia tytułu w moim temacie ?. Miało być Piki, a tu taka kicha wyszła. Nie zauważyłem .

Nie ma przypadków. Bierz się jak najszybciej za te poradniki co poleciłem a wszystko powinno sie wyjaśnić.

P. S. Mirek stworzył program Atnel Video Player, który w darmowej wersji pozwala przeglądać, wyszukiwać i tworzyć bookmarki do wszystkich jego filmików. A w wersji płatnej do dowolnych kanałów na YT koszt niewielki a pozwala po pierwsze ogarnąć swoje ulubione kanały a po drugie jest to najprostszy sposob wsparcia Mirka.

To jest logiczne jak budowa cepa . Pliki z dyrektywy #include są fizycznie wstawiane w miejsce umieszczenia dyrektywy #include. Jak w pliku wstawionym masz odwołanie do jakiejś zdefiniowanej wartości (#define), która wcześniej nie została zaincludowana to kompilator wyrzuci Ci to warningiem/errorem.
Systemowe biblioteki są tak pisane, że jak używane / potrzebne jest coś, to jest to doincudowywane, więc w typowych zastosowania nie ma znaczenia kolejność. Ale jak wrzucisz swój #include przed systemowymi i używasz np. nazw rejestrów to będziesz miał taką sytuację jak opisujesz, bo jeszcze kompilator nie zna ich, bo nie zostały jeszcze doinkludowane odpowiednie "tłumaczenia".

--
Pozdrawiam,
Robert

Robert, daj koledze samemu do tego dojść, bo się nie nauczy

Dzięki jeszcze raz.
Właśnie obejrzałem poradnik. Bardzo dobra pomoc i sporo mi się wyjaśniło, jak również Wasze podpowiedzi i kol. rskup o priorytecie pliku systemowego nad moim własnym. Nie jestem na bieżąco z poradnikami Mirka. Czytałem również w BB o plikach extern, ale jeszcze dopytam. Jeżeli mam kilka plików nagłówkowych.h, ale tylko jeden plik źródłowy.c korzysta z jakiejś
deklaracji w danym pliku.h , to powinno wyglądać tak ?



A jeśli np. dany plik nagłówkowy.h jest "zainkludowany" do kilku plików źródłowych.c , to wtedy musi być tak ?



Czytałem, ale dopytuję .

To niestety musisz jeszcze raz przeczytać

extern używa się dla zmiennych a nie dla funkcji.
Czy zapis jest deklaracją czy definicją, to dla funkcji jest łatwe do rozróżnienia przez kompilator, bo albo masz ciało funkcji albo średnik Dla zmiennych to już tak się nie da (zmienna nie ma ciała ) i aby poinformować kompilator że taka zmienna gdzieś indziej istnieje (ale nie w tym pliku) i jest danego typu daje się extern (bez extern stworzyłbyś w drugim miejscu nową zmienną o takiej samej nazwie).

--
Pozdrawiam,
Robert

Dzięki bardzo.
Rozumiem. Przy okazji sorry za ten masakryczny kod extern void cos_tam(void); Oczywiście chodzi mi o zmienne i bezmyślnie napisałem taki przykład mając w głowie tylko extern, a podpiąłem to
pod funkcję zamiast na przykładzie zmiennej. Napisałem programik, który posiada razem 16 plików dodatkowych (c i h), więc myślę, że chyba pojąłem ideę podziału w miarę przyzwoity sposób.
Opanowałem w końcu, co to definicja funkcji, ciało i deklaracja i jak to rozdzielić, dopisać średnik na końcu i wstawić do .h. Zmieniłem trochę sposób nauki, ponieważ do tej pory coś tam zatrybiłem,
ale nie do końca i szedłem dalej. Wychodziły mi jakieś tam programiki i działały, ale tak na prawdę bez pełnego zrozumienia. W końcu zrozumiałem, że tak się nie da. Im szybciej chciałem, tym wolniej
to idzie. Teraz czytam rozdział kilka razy, poradnik kilka razy i koledzy na forum. Inaczej całe życie będę migał diodami . Dzięki i pozdrawiam.

I o to chodzi. Powodzenia a jak będziesz miał jakieś pytania to zadawaj je na forum - po to jesteśmy, żeby sobie nawzajem pomagać.

Dzięki micky
Tak też i uczynię, nie mniej jednak staram się nie za często pytać, żeby nie zawracać głowy byle czym. Wiadomo, trzeba najpierw samemu pokombinować. Powodzonka.

Dzięki robespierre.
Sorry, że dopiero odpisuję, ale właśnie przeglądałem Posty. Nie zrozumiałem trochę Twojej rady, a mianowicie (nie wiem, jak wstawić cytat):

"Z externami uważaj. Bardzo często świadczyć mogą o złym projekcie lub rozplanowaniu hermetyzacji modułów programu. Jak pokazujesz "gołe dane extern" to ktoś te dane będzie modyfikował. Ogólnie lepiej ich nie pokazywać a jedynie udostepnić funkcję do manipulacji"

Po pierwsze, jak rozumieć "gołe dane extern". Po drugie, kto może je modyfikować i po co. Ja moje kody mam na moim komputerze i ich nie publikuję, ponieważ
jestem początkujący i są zbyt proste, a żeby były godne większego zainteresowania. Zabrzmiało to trochę tajemniczo. Oczywiście nie wystraszyłeś mnie, ale
ciekaw jestem, co miałeś na myśli.
Przy okazji, a żeby stała się większa jasność w temacie "inkludowania" plików, to chciałem jeszcze dopytać. Obejrzałem poradniki, które koledzy sugerowali, ale
zapytam.

-----------------------------------------------------------

Czy powinienem koniecznie dołączyć WSZYSTKIE pliki .h do main.c , które są w projekcie? Są one dołączane do konkretnych plików systemowych typu .c i potem, jeśli dobrze rozumiem te pliki .c są jakby kontynuacją pliku main.c, a więc te pliki .h tak, czy inaczej powinny być widoczne w projekcie. Kiedyś ktoś mi
napisał, że trochę ryzykowne jest inkludowanie poprzez jakieś łańcuszki plików (z pliku na plik, poprzez inny plik......). I czym grozi zbyt częste inkludowanie
czyli ten sam plik .h i w majnie i gdzie indziej. Zauważyłem, że jak dodałem wszystkie pliki .h do main.c , to wszystko było ok. Potem zacząłem wyłączać niektóre
pliki .h w main.c i do pewnego momentu program się kompilował. Do pewnego momentu oczywiście.
Sorry, że jestem taki marudny i dociekliwy, ale tak już mam i jak czegoś do końca nie zrozumiem, to będę męczył. Nie chcę programować na czuja.
Pozdrawiam.

------------------------ [ Dodano po: kilkunastu sekundach ]

Osoba która otrzyma od Ciebie bibliotekę . Jak się uczysz, to jest dla Ciebie odległa rzecz, ale ma znaczenie jak się zaczyna robić poważniejsze rzeczy. Chodzi o to, że jak wystawiasz zmienną na świat, czyli każdy ma do niej dostęp, to może ją dowolnie i w każdym momencie modyfikować. W takiej sytuacji autor biblioteki nie ma na to wpływu, a jeżeli zmiana wartości musi być zwalidowana albo przy okazji zrobić jeszcze jakieś inne zmiany, to pojawia się problem. Dlatego robi się funkcję której wywołanie pozwala zmienić wartość zmiennej a przy okazji wykonać ewentualne inne rzeczy.

Co znaczy wszystkie? Dołączasz te które wykorzystujesz.

--
Pozdrawiam,
Robert

Dzięki Robercie za wyjaśnienie.
jeśli chodzi o naukę, to ja uczę się hobbystycznie, dla własnych potrzeb i raczej nie wiążę z tym jakiś większych planów. Mam już trochę latek i raczej
późno na zmiany .Od wielu lat zajmuję się elektroniką i to również czysto hobbystycznie i w pewnym momencie stwierdziłem, że muszę sięgnąć i po tą
dziedzinę, ponieważ przy pewnych własnych konstrukcjach i wykorzystaniu mikrokontrolera trzeba by go umieć samemu oprogramować.
Oczywiście jest wiele konstrukcji w necie i wsady do nich, ale nic nie można przerobić, zmienić, czy dodać jakieś własne modyfikacje. I tu postanowiłem nauczyć się (nauczyć, może za wiele

powiedziane) trochę na tyle, na ile jest mi to potrzebne i na ile będę w stanie przyswoić to C.
Ponoć do prostych urządzeń wystarczyłby bascom, ale zdecydowałem się na C dzięki książkom Mirka i ponadprzeciętne wsparcie z Jego strony. Tworzy super
poradniki i jest bardzo dużo materiałów na blogu, tym forum itd...Oczywiście pomimo tylu materiałów i nawet wielokrotnego studiowania zawsze pozostają jakieś
pytania, chociażby z powodu słownictwa, terminologii itd..., z którą wcześniej nie miałem do czynienia, ale jak już coś zaskoczę, to na amen .

Co do "wszystkich" plików nagłówkowych, to nie chodziło mi o wszystkie pliki w c, które będę sobie dowolnie inkludował na górze projektu, tylko np:

Mam plik buttons.c, ekran.c, diody.c, itd... i do nich utworzone pliki nagłówkowe: buttons.h, ekran.h, diody.h itd...

I teraz chodziło mi o to, czy buttons.h, ekran.h, diody.h, itd..., czyli wszystkie z tego projektu muszę dołączyć do main.c, czy jeżeli w main.c nie ma ani jednej
linijki kodu dotyczącego np. przycisków, czyli buttons, co nie dołączam buttons.h do main.c. Wystarczy, że jest w buttons.c

Oczywiście dołączyłem wszystkie pliki .h do main.c i potem po kolei je wyłączałem poprzez // i kompilowałem do momentu do kiedy kompilator nie zgłaszał błędów.
Tylko, że to załatwia problem tylko połowicznie, bo przecież nadal pozostaje pewna niewiedza. Ktoś może mi tu zarzucić, że ciągnę ten temat w nieskończoność
i można by tak pisać i pisać, ale ja jestem uparty w dążeniu do celu i lepiej się przyznać, że się czegoś do końca nie rozumie niż iść dalej, bo to się i tak czkawką odbije prędzej czy

później...Pozostaje jeszcze inkludowanie pliku nagłówkowego .h do innych plików źródłowych .c, bo może być taka sytuacja, że np.
kod zawierający obsługę przycisku będzie użyty także w ekran.c i diody.c, a wiec tam również muszę zainkludować buttons.h Jest to dla mnie zrozumiałe i
oczywiste, ale do końca nie pojmuję, jak to się ma z main.c. Czy tam załączam tylko te pliki z rozszerzeniem .h, gdzie jest akurat jakiś kod powiązany z tymi plikami.h. czy po prostu w main.c

bezwzględnie dołączam wszystkie pliki.h z mojego projektu, dlatego, że jest to main.c nazwijmy go powiedzmy guru całego projektu i dla tego tak.
Może trochę pokrętnie to wszystko opisałem, namieszałem, ale myślę, że koledzy zrozumieli, o co mi chodzi. Tak na koniec, to sobie myślałem jeszcze do
niedawna (oczywiście źle myślałem, rzecz jasna), że jakby się tak logicznie zastanowić, to jeżeli podzielę projekt na kilka plików, części, to tak naprawdę
nie musiałbym wcale inkludować jakichkolwiek plików w main.c, ponieważ są one zainkludowane w pozostałych plikach.c i tak czy inaczej powinny być widoczne przez kompilator, jako całość, a jednak

chyba się myliłem.
Wiem, że dużo na ten temat się tu rozpisywałem i chcę już Was nie męczyć, bo jest przecież całe mnóstwo innych niewiadomych, ale pewnie nie jestem jedyny,
kto do końca tego nie zrozumiał i przyda się również innym osobom, jeśli trafia na ten temat. Pozdrawiam.

Jak nie ma w main.c ani jednej linijki kodu powiązanej z funkcjami i zmiennymi z button.c, to nie podłączasz button.h (bo po co?). Ale jak nie korzystasz z niczego to albo znaczy że program nie korzysta z żadnych elementów z tego pliku (no chyba że tam są tylko niezależne od reszty programu funkcje działające na przerwaniach) albo jest to plik który jest "głębiej w drzewie" plików.
Więc jeżeli z buttons.c korzysta tylko inna biblioteka a nie main.c to dołączasz buttons.h to tej biblioteki a nie do main.c.
Taki przykładowy projekt z wyświetlaczem OLED po I2C - w main.c podłączasz OLED.h, bo będziesz coś wyświetlał na wyświetlaczu. Ale main.c nie obchodzi jak ten wyświetlacz jest podpięty i czy potrzebuje coś więcej. Za to OLED.c musi to mieć zdefiniowane i tam podłączasz i2c.h.

Popatrz się w console jak wygląda kompilacja projektu wieloplikowego. Idzie po kolei kompilacja kolejnych plików c. Dlatego jak w danym pliku używasz jakiś wartości z #define, funkcji lub zmiennych z innych plików to musisz poinformować kompilator, że one istnieją i jakiego są typu (zmienne) oraz jakie mają wejścia i wyjścia (funkcje). Dzięki temu kompilator odpowiednio skompiluje kod. Na koniec po kompilacji wszystkich plików do roboty zabiera się linker, który linkuje wszystkie wyniki z kompilacji poszczególnych plików c w jeden wynik. I on już sprawdza czy obiecane kompilatorowi funkcje oraz zmienne znajdują się fizycznie w którymś z plików.
To tak w skrócie. Ale polecam zapoznać się z https://mirekk36.blogspot.com/2016/08/k ... jektu.html

--
Pozdrawiam,
Robert

Dzięki jeszcze raz za wytłumaczenie.
Myślę, że już wszystko jasne. Obejrzałem dodatkowo na spokojnie jeszcze raz poradnik Mirka i myślę, że mogę spokojnie zamknąć temat. Dzięki wszystkim za cierpliwość. Pozdrowionka.