-
Data: 2013-11-24 15:10:00
Temat: Re: Atmel Studio, projekt w wielu plikach i dyrektywa #include
Od: "Grzegorz Niemirowski" <g...@p...onet.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]Atlantis <m...@w...pl> napisał(a):
> Kompilator zwrócił serię błędów, wskazując na plik nagłówkowy
> zaimportowanej biblioteki. Wszystkie one dotyczyły nieznanego typu
> zmiennej: "unknown type name 'uint16_t'" (tudzież uint8_t),
> występującego w deklaracjach nazw funkcji, umieszczonych w owym pliku
> nagłówkowym. Same definicje funkcji w pliku .c już o nic nie krzyczały.
> Doszedłem do tego, że winny jest brak dyrektywy #include <avr/io.h> na
> początku feralnego pliku nagłówkowego, który ze względu na nazwę jest
> sprawdzany przez kompilator jako pierwszy.
Jak to ze względu na nazwę? Kompilator leci po kolei po linijkach kodu.
> Mam teraz następujące wyjścia:
> 1. Umieścić #include już na początku pliku nagłówkowego, ale chyba nie
> jest to zbyt eleganckim wyjściem.
Dlaczego nie? Skoro plik używa tych typów, to powinien zawierać includy
definiujące te typy.
Tutaj jest w ogóle trochę specyficzna sytuacja. Mówimy bowiem o podstawowych
typach dla AVR (i dla innych uC też), które są wykorzystywane praktycznie w
każdym projekcie. Z tego względu praktycznie każdy plik .c będzie miał
includa dla io.h i będzie importować te typy. Często będzie to pierwsza
linijka w pliku .c. Z tego względu jeśli potem jest include biblioteki, to
te typy są już znane i plik .h biblioteki nie musi ich kompilować. Dlatego
autor biblioteki nie zaincludował io.h w pliku .h swojej biblioteki. Po
prostu założył, że Ty to zrobisz w pliku .c i zrobisz to _przed_
includowaniem jego biblioteki.
Przyznam się, że nie wiem jakie wyjście jest tu uznawane za eleganckie. Moim
jednak zdaniem biblioteka powinna zawierać wszystko co potrzeba i jak
zaincludujemy jej plik .h to nie powinniśmy być zmuszaniu do includowania
innych nagłówków definiujących typy wykorzystywane wewnętrznie przez tą
bibliotekę. No chyba, że uznajemy io.h za wyjątek.
> Na różnych przykłądach widzę, że te
> dyrektywy umieszcza się raczej w plikach *.c.
Kompilator analizując plik .c nie może widzieć żadnych nieznanych wyrażeń,
musi mieć wszystko wcześniej zadeklarowane (niekoniecznie zdefiniowane, ale
zadeklarowane tak). Stosujemy więc pliki nagłówkowe żeby udostępniać
deklaracje typów i funkcji, definicje funkcji siedzą w plikach .c.
Tutaj jest sytuacja taka, że plik .h odwołuje się do typów, których nie ma
standardowo w języku C, dlatego w pliku .h może być odwołanie do innego
pliku .h. Nie jest to nic dziwnego w bardziej złożonych projektach.
> 2. Zmienić nazwy plików tak, aby kompilowały się później.
Po pierwsze kolejność kompilacji nie ma nic do rzeczy. Po drugie o
kolejności decyduje plik Makefile albo inny skrypt budujący (zależnie od
środowiska).
> A może istnieje jakiś sposób na poinformowanie kompilatora, żeby
> dołączył określony plik już na samym początku? Albo żeby zmienił
> kolejność kompilacji poszczególnych plików?
Poczytaj sobie jak działa kompilator. Kompiluje oddzielnie poszczególne
pliki .c, zgodnie z tym, co ma wpisane w Makefile. I przestań mylić
kompilację z dołączaniem plików .h. Kolejność kompilacji nie ma nic
wspólnego z kolejnością dołączania. Pytasz o sposób informowania kompilatora
o dołączanie na samym początku. Dołączanie jest przecież realizowane w
kodzie źródłowym poprzez dyrektywy #include. W jakiej kolejności je
napiszesz, w takiej wskazywane przez nie pliki będą dołączane. Poza tym mam
wrażenie, że myślisz, że plik nagłówkowy się dołącza raz na cały projekt.
Nie. On się dołącza w tym miejscu, w którym jest #include. I koniec końców
dołączany jest to jakiegoś jednego, konkretnego pliku .c. Pliki .c są
kompilowane oddzielnie i nie wiedzą o sobie. Dlatego includy często się
powtarzają. Dopiero jak wszystkie pliki .c są skompilowane, to wkracza
linker tworząc wynikowy plik wykonywalny i zapisując w nim skoki pod
określone adresy. Dlatego w jednym pliku .c możesz odwoływać się do funkcji
zdefiniowanej w drugim. Ale ten pierwszy musi znać deklarację.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 2 days, 18 hours, 52 minutes and 5 seconds
Następne wpisy z tego wątku
- 24.11.13 15:10 Grzegorz Niemirowski
- 25.11.13 11:04 Piotr Gałka
- 25.11.13 14:38 Marcin
- 25.11.13 15:16 Piotr Galka
- 25.11.13 15:52 Marcin
- 25.11.13 18:49 Marek
- 25.11.13 19:47 Marcin
- 25.11.13 19:55 Marcin
- 24.11.13 22:06 janusz_k
Najnowsze wątki z tej grupy
- ładowarka zmarła
- Podstawa bezpiecznikowa jako rozłącznik DC
- Napięcie akumulatora wyłączające UPS / jakie nowe akumulatory do UPS?
- nawigacja satelitarna
- SmartLife/Tuya i osuszanie -- mordowanie z zimną krwią...
- Głośnik piezoelektryczny
- Mala autonomiczna kamera monitoringu
- czas na emeryturę i EB
- Generowanie sumy kontrolnej z fragmentu pliku bin
- Re: Mala autonomiczna kamera monitoringu
- HDMI
- Re: Mala autonomiczna kamera monitoringu
- Kamera monitoringu z kartą SIM
- Re: Kamera monitoringu z kartą SIM
- Re: Kamera monitoringu z kartą SIM
Najnowsze wątki
- 2024-07-01 W-wa naklejki wjazd do centrum
- 2024-07-01 ładowarka zmarła
- 2024-07-01 Koder szuka pracy. Koduję w j.: Asembler, C, C++ (z Qt) i D.
- 2024-07-01 Kraków => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-07-01 Białystok => Full Stack Web Developer (.Net Core, Angular6+) <=
- 2024-07-01 Berlin => Technical Rollouter (Radio Systems Software Installation and
- 2024-07-01 Warszawa => Key Account Manager <=
- 2024-07-01 Gdańsk => Programista Full Stack .Net <=
- 2024-07-01 Zabrze => Junior HelpDesk <=
- 2024-07-01 Warszawa => Key Account Manager <=
- 2024-07-01 Bielsko-Biała => Expert Migration Architect (Azure) <=
- 2024-07-01 Mini Netykieta polskich grup dyskusyjnych
- 2024-07-01 Re: Jak wypełnić polecenie francuskiego sądu blokowania niektórych zapytań DNS? Blokując Francję
- 2024-07-01 Re: Powtórne wezwanie na PO-komisję uzdrowi Ziobrę już w 10 dni
- 2024-07-01 CA -- problem z logowaniem