ATNEL tech-forum

Re: Projekt podział na pliki

2017-12-19T11:07:32+01:00

Robert_1967 napisał(a):

Ponieważ moje zapytanie związane jest z tym tematem, to nie zakładam nowego.

Szanowny kolega jest już długo z nami na forum, żeby wiedzieć, że jak się ma jakiś problem to się zakłada nowy wątek .... bo inaczej forum byłoby JEDNYM MEGA WĄTKIEM jakby się tak każdy "dopisywał" - no bez sensu kompletnie.

Dlatego kolega otrzymuje w nagrodę WARNA ...

a ten wątek zamykam .... jednocześnie proszę o nie dopisywanie się do innych wątków tylko zakładanie własnego jak się ma kolejne pytanie ok?

Statystyki: Napisane przez mirekk36 — 19 gru 2017, o 11:07

Re: Projekt podział na pliki

2017-12-19T10:16:59+01:00

Nazwy portów i pinów są ze sobą związane. Dlatego zapis[syntax=c]PORTC &= ~(DCBA_1 | DCBA_2 | DCBA_3 | DCBA_4);[/syntax] jest mało czytelny bo odwołuje się do portu za pomocą bitów których znaczenia trzeba szukać w innym miejscu w kodzie. Jeżeli używasz abstrakcji DCBA_4 to również powinieneś użyć abstrakcyjnego odwołania do portu. Dla mnie poniższy kod byłby czytelniejszy (pomijając fakt, że nie wiadomo co to jest dcba_7()):
[syntax=c]main.c

#include
#include "dcba.h"

int main(void)
{
dcba_init();
_delay_ms(100);
while(1)
{
dcba_7();
}
}

//-----------------------------------------------------

dcba.c

#include

void dcba_init(void)
{
DDRC |= (1< PORTC &= ~((1<}

void dcba_1(void)
{
PORTC &= ~((1<}

void dcba_2(void)
{
PORTC |= (1< PORTC &= ~((1<}

void dcba_3(void)
{
PORTC |= (1< PORTC &= ~((1<}

void dcba_4(void)
{
PORTC |= (1< PORTC &= ~((1<}

//----------------------------------------------------------

dcba.h

#ifndef DCBA_H_
#define DCBA_H_

void dcba_1(void); // 0000
void dcba_2(void); // 0001
void dcba_3(void); // 0010
void dcba_4(void); // 0011

#endif /* DCBA_H_ */[/syntax]

Statystyki: Napisane przez riddik — 19 gru 2017, o 10:16

Re: Projekt podział na pliki

2017-12-19T09:37:57+01:00

Dzięki riddik za odpowiedź na mojego posta.

W takim razie, czy mógłbyś poprawić moje wcześniejsze pliki tak, jak Ty to widzisz ?. Oczywiście są to, Twoje osobiste opinie i
potraktuje to, jako przykład jeden z wielu, ale czy może ktoś jeszcze podzieli się swoimi uwagami ?

Nie na temat Zdrowych i Wesołych Świąt riddik i Do Siego Roku Wszystkim...

Statystyki: Napisane przez Robert_1967 — 19 gru 2017, o 09:37

Re: Projekt podział na pliki

2017-12-19T09:26:37+01:00

Wg mnie includowanie pośrednie nie jest zbyt dobrą praktyką. Ja jeżeli używam jakiejś deklaracji z pliku .h w pliku .c to w tym konkretnym pliku .c robię includa na tą deklarację. Liczenie że zaciągną się includy gdzieś w łańcuszku kolejnych wywołań może być złudne. Nie wiem czy jest to dobra praktyka, wzorzec czy antywzorzec, ale dla mnie przynajmniej każdorazowe includowanie potrzebnych rzeczy w danym pliku .c jest czytelniejsze. #ifndef w .h załatwia sprawę unikania powtórnych includów tego samego. Ponadto jeżeli jest jakiś includ wołany w innym includzie to znaczy że ten pierwszy jest potrzebny tylko w tym drugim includzie a nie w plikach .c. Jeżeli z jakiegoś powodu chciałbym użyć deklaracji z pierwszego .h to zainkludowałbym go bezpośrednio do .c Oczywiście wszystko powyższe jest wyłącznie moją prywatną opinią i moją prywatną praktyką.

Statystyki: Napisane przez riddik — 19 gru 2017, o 09:26

Re: Projekt podział na pliki

2017-12-19T08:36:10+01:00

Witam
Ponieważ moje zapytanie związane jest z tym tematem, to nie zakładam nowego. W tej kwestii wiele napisano i również wiele
czytałem, ale jak w różnych przypadkach, tak i tutaj pozostaje pewien niedosyt i wątpliwości. Obecnie ćwiczę sobie ustawianie
stanów na porcie C. Podzieliłem sobie projekt na pliki źródłowe i wygląda to następująco:

[syntax=c]main.c

#include
#include "dcba.h"

int main(void)
{
DDRC |= DCBA_1 | DCBA_2 | DCBA_3 | DCBA_4;
PORTC &= ~(DCBA_1 | DCBA_2 | DCBA_3 | DCBA_4);
_delay_ms(100);

while(1)
{
dcba_7();
}
}

//-----------------------------------------------------

dcba.c

#include "dcba.h"

void dcba_1(void)
{
PORTC &= ~(DCBA_1 | DCBA_2 | DCBA_3 | DCBA_4);
}

void dcba_2(void)
{
PORTC |= DCBA_4;
PORTC &= ~(DCBA_1 | DCBA_2 | DCBA_3);
}

void dcba_3(void)
{
PORTC |= DCBA_3;
PORTC &= ~(DCBA_1 | DCBA_2 | DCBA_4);
}

void dcba_4(void)
{
PORTC |= DCBA_3 | DCBA_4;
PORTC &= ~(DCBA_1 | DCBA_2);
}

//----------------------------------------------------------

dcba.h

#ifndef DCBA_H_
#define DCBA_H_

#include

#define DCBA_1 (1<#define DCBA_2 (1<#define DCBA_3 (1<#define DCBA_4 (1<

void dcba_1(void);// 0000
void dcba_2(void);// 0001
void dcba_3(void);// 0010
void dcba_4(void);// 0011

#endif /* DCBA_H_ */[/syntax]

Program kompiluje się prawidłowo i działa dobrze, ale proszę o wyjaśnienie, czy aby na pewno dobrze napisany. Czytałem, że np.
biblioteka #include musi być wszędzie dołączana, ponieważ jest to podstawowa biblioteka C. Ja w main.c mam tylko
#include , ponieważ używam po konfiguracji portu. Nie dołączałem biblioteki #include ani w main.c
ani w dcba.c. Dopiero jest ona dołączona w dcba.h. Oczywiście dcba.h jest zainkludowana do dcba.c i main.c. Czy tak powinno być,
jak ja napisalem ?. Pytanie to jest w szerszym znaczeniu, ponieważ tyczy się innych plików w podobnych sytuacjach.
Wiem, że zapytanie śmieszne i na bardzo początkującym poziomie, ale bez zrozumienia tego potem same problemy. Oczywiście
inkludowałem przykładową bibliotekę we wszystkich plikach projektu tak dla sprawdzenia, ale niczego to nie wnosi. program i tak
się kompiluje bez problemu, tylko gdzie lezy prawda ?. Jak powinno być.
Proszę o jakieś szersze Wytłumaczenie zasad, jeśli ktoś znajdzie chwilę i chęci. Wiem, że w BB jest i czytałem, ale każdy chwyta
inaczej... Pozdrawiam.

Statystyki: Napisane przez Robert_1967 — 19 gru 2017, o 08:36

Re: Projekt podział na pliki

2017-10-05T10:49:43+01:00

roske napisał(a):

Zealota napisał(a):

Jeszcze muszę zapytać o "nieużywanie zmiennych globalnych". Sam często spotykam się z taką tezą, ale szczególnie precyzyjnego wyjaśnienia to nie znalazłem.

Nie ma dużo do wyjaśniania - tak konstruujesz kod by nie było zmiennych globalnych: wszelkie zmienne zamykasz albo w funkcji z dostępem przez argumenty funkcji i zwracaną wartość albo co najwyżej w ramach modułu (jednostki kompilacji) a dostęp do takich zmiennych robisz przez tzw. settery i gettery.
Przy AVRowych ISR definiujesz zmienne w ramach modułu czyli jako "static volatile". Obejrzyj sobie bibliotekę do UART Petera Fleury, tam jest to bardzo ładnie zrobione.

Niestety nie odpowiedziałeś na moje pytanie. Pytałem dlaczego, a nie jak to zrobić.
No bo oszczędzę pamięć? Czy łatwiej zdebuguję, czy może jeszcze co?

Statystyki: Napisane przez Zealota — 5 paź 2017, o 10:49

Re: Projekt podział na pliki

2017-10-05T10:17:48+01:00

Skoro tak rozkładamy te zmienne na czynniki pierwsze, to mam pytanie.

Dlaczego, jeśli zdefiniujemy zmienną globalną np. w projekcie jedno-plikowym typu uint8_t to "Data: 1 bytes" natomiast jeśli tą sama zmienną przy definicji inicjujemy jakąś wartością, to po kompilacji mamy: "Data: 2 bytes" ??? W przypadku zmiennych zajmujących więcej niż jeden bajt już tak nie jest (czy inicjujemy ją czy nie, po kompilacji rozmiar .data odpowiada jej faktycznemu rozmiarowi).

Kolejna sprawa - mechanizm "tentative definition" (tutaj dowiedziałem się, że w ogóle coś takiego jest - nie wiem też czy go dobrze zrozumiałem)- zauważyłem, że gdy w różnych plikach zdefiniujemy trzy takie same zmienne, ale różniące się typem (8, 16 i 32 bity) i ich nie inicjujemy żadną wartością, to kompilator przy .data pokazuje nam wielkość największej z nich (coś ala unia), gdy inicjujemy jedną (Tylko jedną) z nich, to po kompilacji .data pokazuje wielkość tej, którą inicjowaliśmy i wywala wora (nie wywala go, gdy inicjujemy zmienną 16 bitową - jakaś może promocja do int ??? ). Co ciekawe, przy braku inicjacji takich zmiennych, gdy w funkcji nadamy im wartość i przekroczymy zakres (np. w pliku mamy zmienną 8 bitów, wpiszemy 300, lub w innym pliku mamy 16 bitów i wpiszemy 300000) to dostajemy o tym wora. Wygląda to tak, że kompilator rezerwuje miejsce dla największej z nich, a i tak pilnuje ich wielkości w danym pliku.
I jeszcze jeden ciekawy eksperyment - ta sama nazwa zmiennej o różnym rozmiarze w trzech różnych plikach. Inicjujemy tylko tę 16 bitową - brak worningów. W pliku, gdzie zmienna jest 32 bitowa piszemy funkcję, która przypisuje jej wartość 1000000 - poza zakresem zmiennej 16 bitowej. Po kompilacji: ".data 2". Możemy tą funkcję wywołać w main. Zero worningów. Ciekawe, gdzie on zmieści ten 1000000;
Chyba dziś to po testuję na LCD....

I ostatnie pytanie - jeśli w jakimś pliku użyjemy jakiejś nazwy zmiennej (i ją zainicjujemy), to nie możemy jej już użyć nigdzie indziej, mimo, że bez extern nie mamy do niej dostępu. Jak sobie z tym radzą programiści - np. jeden pisze bibliotekę i użyje np. zmiennej licznik, drugi w swojej bibliotece także użyje tej samej nazwy. Trzeci programista połączy te dwie biblioteki i bach - error. Co wówczas? prze-edytować jedną z bibliotek i zmienić nazwy? W definicji jednej ze zmiennych dodać static? Dobrze jak to jest małe, ale jak np. piszą gry (wiem, wiem nie piszą w C, choć nie wiem czy np. w C++ nie jest podobnie) lub inne duże programy.

Statystyki: Napisane przez APAP75 — 5 paź 2017, o 10:17

Re: Projekt podział na pliki

2017-10-05T09:54:38+01:00

kisiel napisał(a):

Zealota napisał(a):

"Pamiętaj, aby w pliku nagłówkowym nigdy nie umieszczać definicji, powinny tam znajdować się wyłącznie deklaracje.
Nielicznymi wyjątkami są definicje zmiennych typu const oraz krótkich funkcji"

W przytoczonym fragmencie jest napisane że nie powinno się ale skoro są wyjątki, standard to dopuszcza, dopiero DOBRA PRAKTYKA programowania tego zabrania. Ot różnica o którą mi cały czas chodzi.

W przytoczonym fragmencie napisane jest "nigdy" i to się tyczy zmiennych, o których rozprawialiśmy w całym tym wątku.
Co prawda za chwilę jest "powinno", więc dość ciężko się zdecydować, być może dlatego później takie dysputy jak nasza ...

Nikt z uczestników dyskusji nawet nie wspomniał o przypadku const, prawdopodobnie po prostu nikt tego nie wiedział, na pewno ja nie wiedziałem.
Należało użyć tego argumentu i tyle.

Jeszcze muszę zapytać o "nieużywanie zmiennych globalnych". Sam często spotykam się z taką tezą, ale szczególnie precyzyjnego wyjaśnienia to nie znalazłem.
Wg mnie, dla procesorów AVR, jest to niemożliwe, jeśli korzystamy np z przerwań, gdzie musimy korzystać ze zmiennych globalnych.
No chyba, że można samemu definiować funkcje ISR, tak by podawać dodatkowe parametry - ale czy to nie byłby jakieś nadużycie.

Statystyki: Napisane przez Zealota — 5 paź 2017, o 09:54

Re: Projekt podział na pliki

2017-10-05T07:46:02+01:00

Zealota napisał(a):

Statystyki: Napisane przez kisiel — 5 paź 2017, o 07:46

Re: Projekt podział na pliki

2017-10-04T23:44:39+01:00

roske napisał(a):

Wszystkie zmienne definiowane poza ciałem funkcji opatruje się specyfikatorem 'static', wtedy ich zasięg i widoczność ograniczają się do danej jednostki kompilacji.

A kto mówił inaczej ?

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

roske napisał(a):

W zamieszaniu umknęła wam, ludkowie

a to już TYPOWE chamskie teksty zadętych Śpeców co to obrażają wszystkich - nie mając już żadnych innych argumentów

------------------------ [ Dodano po: 18 minutach ]

roske napisał(a):

Zmienne globalne są gorsze nawet od instrukcji "goto". Naprawdę. I nie wierzcie gdy ktoś, kimkolwiek by nie był, mówi inaczej.

Widzisz roske - przez twoje ZADĘCIE nawet nie zauważyłeś, że ZAWSZE to samo powtarzam ... ale nie ma to jak odkryć koło od nowa

hasta lawista dziecko

------------------------ [ Dodano po: 20 minutach ]

roske napisał(a):

Jedynie naprawdę ważna z wszystkiego co tu powiedziano: zmiennych globalnych się NIE używa.

hahahaha jak się okazało że kolega roske - w końcu zrozumiał co znaczy "tentative definition"

to w końcu zaczyna mówić tym samym językiem

roske

roske napisał(a):

Jedynie naprawdę ważna z wszystkiego co tu powiedziano: zmiennych globalnych się NIE używa.

nie się "NIE" używa - lecz ... panie kochany - ZALECA się nie używać .... a gdzież twoje wcześniejsze bzdury o tym że zmienne globalne to całkiem innego niż opowiadałeś bajki - nie wiedząc co to oznacza: "tentative definition"

------------------------ [ Dodano po: 21 minutach ]

hahahaa nie ma to jak edytować swój post gdy się bzdur nagadało co ?

Statystyki: Napisane przez mirekk36 — 4 paź 2017, o 23:44

Re: Projekt podział na pliki

2017-10-04T20:45:47+01:00

Chłopaki, dajcie już spokój z tymi kłótniami - niech robią jak chcą, w końcu to oni będą mieli kiedyś problemy.
Dopóki nie uczą innych jest ok

Statystyki: Napisane przez Harry — 4 paź 2017, o 20:45

Re: Projekt podział na pliki

2017-10-04T20:40:48+01:00

kisiel napisał(a):

mirekk36 napisał(a):

Ja bym się z tym nie zgodził - bo wg mnie definiowane zmiennych w plikach *.h to BŁĄD i nie jest to niezalecane - tak się nie robi w

WEDŁUG CIEBIE - Ale na szczęście to nie Ty definiujesz standard.

Dobrze byłoby poznać źródło w literaturze tych zdecydowanych twierdzeń.

Próbowałem poszukać jakiegoś podparcia do rozsądzenia tej wątpliwości. Ciężko jest. Oczywiście przeglądnąłem książki, które mam.
Nie znalazłem nic co by potwierdzało Twoją wersję. Być może jestem źle nastawiony, ale jedynie co znalazłem to:
Tomasz Francuz "AVR. Praktyczne projekty"
"Pamiętaj, aby w pliku nagłówkowym nigdy nie umieszczać definicji, powinny tam znajdować się wyłącznie deklaracje.
Nielicznymi wyjątkami są definicje zmiennych typu const oraz krótkich funkcji"
No to Co? Tomasz Francuz też się myli?
Naprawdę trudno zaakceptować Twoje zalecenia, bo niczym tego nie popierasz.

Póki co ja zapamiętuję, żeby NIE UMIESZCZAĆ. Dwa źródła, które znalazłem wskazują jednoznacznie, żeby tego nie robić. Z chęcią poznam jeszcze coś, co temu zaprzecza.

Każdy może sobie wybrać jak pracować, ale w przypadku obwieszczania "w internecie" swoich racji to warto mieć jakieś poparcie.

Statystyki: Napisane przez Zealota — 4 paź 2017, o 20:40

Re: Projekt podział na pliki

2017-10-04T19:47:04+01:00

kisiel napisał(a):

Myślę że tym programem obaliłem ostatni mit na temat tego że zmienne są globalne tylko w momencie dopisania extern - poniakąd to jest prawda, ale to extern jest niejawnie dopisywane przez kompilator.

Napisałeś bzdurę bo "tentative definition" to nie ŻADNE dopisywanie extern przez kompilator - i żadnego mitu nie obaliłeś, Bo to że kompilator podłoży kilku zmiennym o tej samej nazwie TEN SAM ADRES w ram - NIE MA NIC WSPÓLNEGO ze zmienną globalną. A teksty, że kompilator "łyknie" a tylko kompilator sobie nie radzi to już zupełny odlot.

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

kisiel napisał(a):

Twojego podejścia do osób, które się z Tobą nie zgadzają.

kisiel napisał(a):

Reszta to zwykłe oszczerstwa i obrażanie mojej osoby. Nic nie wiesz na temat jakie kody piszę, jak pracuje w grupie ani jak realizuje projekty. Ja w żadnym poście nie napisałem nic na temat Twojego zachowania, Twojego podejścia do osób, które się z Tobą nie zgadzają. Po prostu skandal i żenada. Tyle ode mnie.

No no i kot odwrócony ogonem - zostawię to i niech każdy sobie oceni w tym całym wątku co i jak .... tymczasem ja panie kochany, ponieważ dla mnie tajemnica korespondencji mailowej to rzecz święta, nie będę tu przytaczał cytatów z tego co ty do mnie napisałeś na PW i jakie oszczerstwa - i tylko dlatego, że ja się nie zgadzałem z twoim podejściem - napisałem ci na PW, tylko że to co przeczytałem od ciebie w mailu to dziecinada ...

Ja niby źle traktuję osoby które się ze mną nie zgadzają - a jak ty traktujesz takie osoby kochany ? Żegnam cię i życzę ci powodzenia.

Statystyki: Napisane przez mirekk36 — 4 paź 2017, o 19:47

Re: Projekt podział na pliki

2017-10-04T18:20:39+01:00

mirekk36 napisał(a):

zatem zmyślne teorie kolegów roske i kisiel upadają, żeby nie było proszę obrazek

To samo zaprezentowałem tutaj - zero nowości,
topic19291-30.html#p196297

Czy muszę wspominać również że nigdzie w kodach, które zaprezentowałem nie występuje taka konstrukcja jak definicja 2 tych samych zmiennych w 2 plikach?

------------------------ [ Dodano po: 5 minutach ]

mirekk36 napisał(a):

Ja bym się z tym nie zgodził - bo wg mnie definiowane zmiennych w plikach *.h to BŁĄD i nie jest to niezalecane - tak się nie robi w C. Oczywiście - jeśli ktoś zrobi to czasem nie wywoła to błędów bo język C nie traktuje tego jako błąd syntaktyczny ale niestety można się do tego przyzwyczaić jak kisiel i weź wtedy po kilku latach wyjaśnij takiej osobie że tak się nie robi - a ona twierdzi że programuje zawodowo od kilku lat więc wie co robi ... Tyle że nie wierzę, że w ciągu tych kilku lat nie pojawiły się problemy przy takim podejściu - ale pewnie były rozwiązywane "na partyzanta" i jakoś tam szło dalej - więc nie znając zasad - można taki błąd wciąż powielać i powielać

WEDŁUG CIEBIE - Ale na szczęście to nie Ty definiujesz standard. Reszta to zwykłe oszczerstwa i obrażanie mojej osoby. Nic nie wiesz na temat jakie kody piszę, jak pracuje w grupie ani jak realizuje projekty. Ja w żadnym poście nie napisałem nic na temat Twojego zachowania, Twojego podejścia do osób, które się z Tobą nie zgadzają. Po prostu skandal i żenada. Tyle ode mnie.

Statystyki: Napisane przez kisiel — 4 paź 2017, o 18:20

Re: Projekt podział na pliki

2017-10-04T11:46:43+01:00

A w tzw międzyczasie bo też mam takie zacięcie, żeby wszystko samemu sprawdzić a do tej pory (może wstyd się przyznać) ale nie miałem i nie używałem żadnego kompilatora C na PC pod windowsem, więc nie mogłem do końca sprawdzić np ew różnic w kompilacji pomiędzy tym co opowiadał roske albo kisiel.

Zainstalowałem więc sobie CodeBlocks + kompilator MinGW i stworzyłem identyczny projekt testowy - no i proszę - jeśli w więcej niż jednym pliku inicjalizujemy zmienną "dwa" to KICHA - tu nawet nie zadziała tentative definition, tylko kompilator zwymiotuje błędem "multiple definitions"

zatem zmyślne teorie kolegów roske i kisiel upadają, żeby nie było proszę obrazek. A przy okazji obaj koledzy dowiedzieli się, o co chodzi z tentative definition a jednocześnie mam nadzieję, że zrozumieli jak działa mechanizm zmiennych globalnych w C i jak należy prawidłowo do tego podchodzić.

Statystyki: Napisane przez mirekk36 — 4 paź 2017, o 11:46

Re: Projekt podział na pliki

2017-10-04T10:27:38+01:00

Zealota napisał(a):

Zapis ten, wg mnie, sugeruje, że tylko jawna (przez użytkownika) inicjalizacja zmiennej zrobi z tego zapisu definicję
Jeśli nie sugeruje tego autor intencjonalnie, to sam zapis i brak wyjaśnienia mąci innym w głowach, bo faktycznie użytkownik nie musi jawnie inicjować zmiennej, żeby była definicją, zrobi to automatycznie kompilator - bo taki jest standard języka C.

I właśnie na takim czymś - wg takich materiałów uczy się część osób programować w C a później po kilku latach używania tego - jak kolega kisiel - piszą, że tutaj ja opowiadam jakieś bzdury albo swoje zasady na temat języka C

------------------------ [ Dodano po: 5 minutach ]

Zealota napisał(a):

Niestety, jak wiemy z wątku, to bardzo potrzebne "extern" jest najczęściej doklejane przez kompilator jeśli go brakuje w plikach nagłówkowych, stąd mogą rodzić się nieporozumienia.

No tutaj bym tylko doprecyzował , że kompilator nie dokleja extern .... za to próbuje włączać mechanizm "Tentative definitions" czyli próbuje sprawdzać czy pojawiły się aby przypadkiem dwie TAKIE SAME definicje TAKIEJ SAMEJ zmiennej tzn o TAKIEJ SAMEJ nazwie, co więcej sprawdza czy tylko w jednym przypadku zmienna została ew jawnie zainicjalizowana a jeśli tak - to przydzieli w przypadku każdej z tych definicji JEDEN adres w RAM a zatem niejako sklei je w JEDNĄ zmienną. Czyli nie ma to nic wspólnego z doklejaniem extern tak wprost. ALE WARTO wiedzieć jak to działa bo to pozwoli nam często wyszukać jakiś dziwny błąd ....

------------------------ [ Dodano po: 7 minutach ]

Zealota napisał(a):

Powrócę za to jeszcze do rodzaju zmiennych, czy lokalna czy globalna.
Uknułem sobie taką oto skrótową definicję: każda definicja zmiennej wewnątrz funkcji robi z niej zmienną lokalną.
Wszystkie inne definicje (poza funkcjami, również poza main() ) to są zmienne globalne, są bowiem umieszczone w sekcji zmiennych globalnych, ale o różnym zakresie widoczności, którą definiuje użytkownik poprzez deklarację zmiennych w odp. plikach nagłówkowych, które to następnie można inkludować do kolejnych plików źródłowych rozszerzają widoczność na inne moduły.

No i bardzo dobra teoria - chociaż ja również piszę już o tym w Bluebooku ale zrozumiałe jest - że nie od razu czasem wszystko do nas dotrze z jednego źródła - dlatego warto wtedy sięgać również do innych książek - rzadziej tylko do internetu bo jak widać po powyższym twoim przykładzie można w 50% trafić na takie bzdury że szok

------------------------ [ Dodano po: 11 minutach ]

Zealota napisał(a):

Definiować zmienne można również w plikach nagłówkowych (nie spowoduje to błędów kompilacji), ale nie jest to zalecenie (silnie niezalecane), bo może powodować lawiny błędów, szczególnie przy rozbudowanych, wieloplikowych projektach.

Zealota napisał(a):

Ja bym jeszcze dodał jeszcze, że ten zapis powyższy będzie poprawny tylko i wyłącznie w jakiejś funkcji zdefiniowanej w main.c.
Proszę o komentarz, ja spróbuję tak skomentować.

OCZYWIŚCIE sorki mój błąd - powinienem to był napisać w ramach np funkcji main() i zaraz to na górze poprawię. DZIĘKI za sprostowanie i wskazanie mojego błędu

------------------------ [ Dodano po: 16 minutach ]

Zealota napisał(a):

Oczywiście wymądrzam się, bo sobie zrobiłem projekt i dostałem błędy, a potem wymyśliłem odpowiedź

eeee tam jakie wymądrzanie - mnie osobiście bardzo się podoba tego typu dochodzenie do pewnych wniosków, na forum niewiele osób tak jak ty - testuje pewne rzeczy na żywym organizmie ... tak na gorąco - to chyba przychodzi mi na myśl tu nick kolegi Daro69 - który również dzięki takiemu podejściu - jak ja obserwuję co wyrabia na forum - to BARDZO szybko podnosi swój skill w C

Statystyki: Napisane przez mirekk36 — 4 paź 2017, o 10:27

Re: Projekt podział na pliki

2017-10-04T09:41:03+01:00

Szanowni Czytelnicy, jeszcze pociągnę temat deklaracji i definicji, bo chyba wreszcie wbiłem sobie to do głowy, może komuś jeszcze to pomoże.
Przygotowałem kilka cytatów z czeluści ksiąg tajemnych i internetów

Cytat z niniejszego wątku:

mirekk36 napisał(a):

1. extern int dwa;
2. int dwa;

czym to się różni ? otóż PIERWSZY zapis to DEKLARACJA z linkowaniem zewnętrznym (external linkage)
DRUGI zapis to jest panie DEFINICJA a ta dzięki regułom "tentative definition" jest również z linkowaniem zewnętrznym (external linkage) Dzięki czemu może w ogóle dojść do połączenia definicji zmiennej dwa w twoim przykładzie pod jednym adresem w RAM.

Na potwierdzenie jeszcze raz to samo źródło, czyli BB. Pozwolę sobie zacytować cześć dot. zmiennej:
"Przykłady Deklaracji:
extern int a1;
extern uint8_t tab[];
Przykłady Definicji:
int b1;
int c2 = 5;" Koniec cycatu

Szukamy zatem innego źródła: "Podstawy języka C++" Stanley B. Lippman"

"Definicja zmiennej służy do zarezerwowania dla tej zmiennej, wprowadzenia jej nazwy i określenia typu"
"Deklaracja służy do oznajmiania, że zmienna taka istnieje i została zdefiniowana w innym miejscu programu. Deklaracja składa się ze specyfikatora typu oraz nazwy zmiennej, poprzedzonych słowem kluczowym extern"

Najważniejszy wniosek dla mnie tutaj płynie taki, że jawne pisanie extern wskazuje bezbłędnie na deklarację, zatem używajmy go wszędzie gdzie trzeba, nie liczmy na kompilator. Poprawne użycie tego słowa zwiększa czytelność kodu!

A teraz pojęcia prosto z "interneta":
http://cpp0x.pl/forum/temat/?id=20322
No i mamy podsumowanie:
[syntax=c]int x; //deklaracja
x = 10; //inicjalizacja
int y = 5; // definicja = deklaracja + inicjalizacja[/syntax]

Zapis ten, wg mnie, sugeruje, że tylko jawna (przez użytkownika) inicjalizacja zmiennej zrobi z tego zapisu definicję
Jeśli nie sugeruje tego autor intencjonalnie, to sam zapis i brak wyjaśnienia mąci innym w głowach, bo faktycznie użytkownik nie musi jawnie inicjować zmiennej, żeby była definicją, zrobi to automatycznie kompilator - bo taki jest standard języka C.
Zatem każda definicja zmiennej rezerwuje pamięć i daje jej wartość. Użytkownik oczywiście tę wartość może zmienić, ale to banał

Zapis:
[syntax=c]int x; // deklaracje[/syntax]
to oczywisty błąd, zapis ten nie jest deklaracją.
Linijka ta oczywiście jest definicją, bo nie zawiera słowa kluczowego "extern". Niestety, jak wiemy z wątku, to bardzo potrzebne "extern" jest najczęściej doklejane przez kompilator jeśli go brakuje w plikach nagłówkowych, stąd mogą rodzić się nieporozumienia.

No i chyba wreszcie zaskoczyło i łatwiej mi już dzielić na pliki, błędów nie ma i jest git

Powrócę za to jeszcze do rodzaju zmiennych, czy lokalna czy globalna.
Uknułem sobie taką oto skrótową definicję: każda definicja zmiennej wewnątrz funkcji robi z niej zmienną lokalną.
Wszystkie inne definicje (poza funkcjami, również poza main() ) to są zmienne globalne, są bowiem umieszczone w sekcji zmiennych globalnych, ale o różnym zakresie widoczności, którą definiuje użytkownik poprzez deklarację zmiennych w odp. plikach nagłówkowych, które to następnie można inkludować do kolejnych plików źródłowych rozszerzają widoczność na inne moduły.

Definiować zmienne można również w plikach nagłówkowych (nie spowoduje to błędów kompilacji), ale nie jest to zalecenie (silnie niezalecane), bo może powodować lawiny błędów, szczególnie przy rozbudowanych, wieloplikowych projektach.

------------------------ [ Dodano po: 26 minutach ]

mirekk36 napisał(a):

main.c
[syntax=c]#include "common.h"

mojastruktura.ala = 23;
int a = mojastrutura.as;[/syntax]

Ja bym jeszcze dodał jeszcze, że ten zapis powyższy będzie poprawny tylko i wyłącznie w jakiejś funkcji zdefiniowanej w main.c.
Proszę o komentarz, ja spróbuję tak skomentować.

1. Dostępu do pól struktur nie ma w sekcji zmiennych globalnych. Jedynie podczas definiowania zmiennej można ją zainicjalizować po swojemu:
TMYSTRUCT mojastruktura = {7,2};

2. Zmiennych globalnych nie można inicjować zmiennymi, tylko stałymi. Stąd m.in. częsty błąd podczas kompilacji:
"error: initializer element is not constant."

Oczywiście wymądrzam się, bo sobie zrobiłem projekt i dostałem błędy, a potem wymyśliłem odpowiedź

Statystyki: Napisane przez Zealota — 4 paź 2017, o 09:41

Re: Projekt podział na pliki

2017-10-04T09:39:10+01:00

APAP75 napisał(a):

Tam, gdzie includuję comon.h i z niej korzystam jest niby ok - program się kompiluje, nie wywala błędów, ale robiłem to trochę jak ruski saper - "na macajewa".

Nie, nie zrobiłeś jak ruski saper - zrobiłeś MEGA POPRAWNIE:

common.c
[syntax=c]#include "common.h"

TMYSTRUCT mojastruktura;[/syntax]

common.h
[syntax=c]typedef struct {
uint8_t ala;
int as;
} TMYSTRUCT; // definiujemy nowy typ strukturalny

extern TMYSTRUCT mojastruktura;[/syntax]

main.c
[syntax=c]#include "common.h"

int main( void ) {
mojastruktura.ala = 23;
int a = mojastrutura.as;

while(1) {
}[/syntax]

Statystyki: Napisane przez mirekk36 — 4 paź 2017, o 09:39

Re: Projekt podział na pliki

2017-10-04T09:29:39+01:00

A jak postępować ze zmiennymi będącymi strukturami?
W wielu miejscach natchnąłem się: "ten iclude musi być pierwszy bo inaczej nie działa"

Zrobiłem mały test - definicję nowego TYPU zmienne strukturalnej wrzuciłem do common.h, definicję ZMIENNEJ strukturalnej do common.c, deklarację tejże zmiennej (ze słowem extern) do common.h.
Tam, gdzie includuję comon.h i z niej korzystam jest niby ok - program się kompiluje, nie wywala błędów, ale robiłem to trochę jak ruski saper - "na macajewa".

Statystyki: Napisane przez APAP75 — 4 paź 2017, o 09:29

Re: Projekt podział na pliki

2017-10-03T20:05:38+01:00

Wydaje mi się, że już kiedyś o tym i to tobie pisałem - ale może mi się wydaje więc jeszcze raz:

procek87 napisał(a):

Co zrobić jeśli main.c nie ma swojego pliku nagłówkowego

A dlaczego piszesz, że on nie ma swojego pliku? A kto tak powiedział? toż to od ciebie zależy, toż możesz sobie stworzyć plik main.h - kto ci zabroni - i tak czasem ludzie robią - ale mi się to nie do końca podoba osobiście , ja wolę nieco inne podejście - ale to tylko moja propozycja a nie że ja mówię że tak trzeba. Ja po prostu tak robię w swoich programach.

PO PIERWSZE - ZAWSZE warto umieszczać zmienne w plikach z którymi one się jakoś wiążą logicznie, w których są najczęściej używane a rzadziej będą używane w innych plikach projektu.

Podajesz tu przykład troszkę oczywiście oderwany od rzeczywistości - ale fajnie że prosty przykład oczywiście ...

otóż zakładając, że zmienna pomoc miałaby być wykorzystywana zarówno w main.c ale też w innych przypadkowych plikach projektu - to ja z marszu zakładam sobie w ścieżce głównej projektu od razu dwa pliki:

common.c
common.h

i już sam czujesz, że właśnie umieściłbym jej definicję w pliku common.c zaś deklarację w common.h a następnie tam gdzie będę jej potrzebował czy to w main.c czy w innych plikach - rozumiesz? Zawsze w plikach "common" wtedy umieszczam tego typu wspólne i nie mające logicznego powiązania zmienne z konkretnym modułem. Podobnie z jakimiś wspólnymi funkcjami czy definicjami preprocesora

ALE ... ty tu w tym przykładzie napisałeś że potrzebujesz zrobić pliki

main.c

pomoc.c
pomoc.h

no to jak widzę nazwę zmiennej "pomoc" to sam powiedz - nie wiąże się ona logicznie z tymi plikami pomoc.c -.h ??? A jeśli tak to niestety wymyśliłeś NAJMNIEJ zdrowe podejście, żeby:

a) DEFINICJĘ tej zmiennej walnąć w main.c
b) DEKLARACJĘ tej zmiennej dać w pomoc.h

ja bym jak pisałem wyżej dał jej definicję w pomoc.c, jej deklarację w pomoc.h i zainkludowałbym w main.c plik pomoc.h

Mam nadzieję, że teraz jaśniej

Statystyki: Napisane przez mirekk36 — 3 paź 2017, o 20:05

Re: Projekt podział na pliki

2017-10-03T19:39:42+01:00

Mirku jeszcze jedno w tym temacie bo dziś na to się natknąłem a o to nie spytałem i nie daje mi św.spokoju , nasunęło mi się kolejne pytanie , podejrzewam jak postąpić ale nie jestem pewien dlatego popraw mnie .

definiuje załużmy zmienną globalną w main.c w projekcie składającym się z plików main.c i pomoc.c

Code:

//***main.c

int globalna=4;  // zmienna globalna, którą chce uwidocznić w pliku pomoc.c

int main(void){
}

Co zrobić jeśli main.c nie ma swojego pliku nagłówkowego i nie można przerzucić do niego deklaracji zmiennej globalnej extern,
bo nie ma pliku main.h przerzucić tą deklaracjie extern int globalna do pomoc.h , by uwidocznić ją, dla pliku pomoc.c , w którym chce się zapewnić dostęp do niej ?

ja bym przerzucił deklaracjie do pliku nagłówkowego pomoc.h , ale nie wiem czy dobrze myśle?

main.c

Code:

//***main.c

int globalna=4;

int main(void){
orange();
}

pomoc.c

Code:

//**pomoc.c

void orange (void){
globalna=6
}

}

Code:

//**pomoc.h
#ifndef GH_H_
#define GH_H_


extern int globalna;

void orange(void);

#endif /* GH_H_ */
}

Statystyki: Napisane przez procek87 — 3 paź 2017, o 19:39

Re: Projekt podział na pliki

2017-10-03T14:38:01+01:00

Zealota napisał(a):

"Obie są globalne, bo jedną zdefiniowano w main.c, a drugą w foo.c, obie w sekcjach zmiennych globalnych oraz zmienna dwa, poprzez extern, jest widoczna w main.c i jest globalna."

no tak - obie zmienne o nazwie "dwa" w obu plikach są globalne względem tych plików ale dzięki "Tentative definitions" posiadają coś takiego jak "external linkage" dzięki czemu kompilator może te dwie zmienne o nazwie "dwa" widzieć pod jednym adresem RAM. Ale jak już zdążyłem napisać w kolejnym poście - gdyby w ten sposób chcieć korzystać z globalności zmiennych - to sam popatrz zamiast dawać zmienną "dwa" tak jak "jeden" ze specyfikatorem extern do pliku "h" to co ? logicznym wydaje się napierniczanie w KAŻDYM pliku w którym chcesz użyć tej zmiennej "dwa" aby była widoczna w całym projekcie ???? Toż to byłaby bzdura a pomyśl o bibliotekach to już w ogóle nie dałoby rady zrobić - bo byś musiał kazać użytkownikowi swojej biblioteki definiować w KAŻDYM własnym pliku zmienną "dwa" zamiast przekazać ją jako "extern int dwa" przez plik nagłówkowy biblioteki ... no tu roske popłynął

mirekk36 napisał(a):

Natomiast dwa jest zmienną globalną, bo umieszczono ją w sekcji zmiennych globalnych pliku foo.c, ale nie jest widoczna dla innych modułów, nawet jeśli includują foo.h, bo nie ma jej deklaracji poprzedzonej extern w pliku foo.h?

Tak nie jest widoczna dokąd nie zadziała Tentative definitions - co WCALE NIE SPOWODUJE, że każda z nich stanie się widoczna dla innego pliku ale spowoduje, że kompilator zrobi porządek za plecami i obydwie zmienne przypisze do JEDNEGO adresu w RAM ... i będzie to dziwnie wyglądało nieprawdaż ?

Zealota napisał(a):

Czy może robi się z niej lokalna, bo zabrakło extern i deklaracji w nagłówku foo.h?

Nie, jest tak jak wyżej doprecyzowuję

Zealota napisał(a):

A może brak widoczności, pomimo umieszczenia w sekcji zmiennych globalnych, automatycznie robi ze zmiennej lokalną?

też nie - patrz wyżej "Tentative definitions"

Zealota napisał(a):

Co zatem ze zmienną static w jakiejś funkcji.
Piszą, że to jest "zmienna lokalna, ale umieszczona w sekcji zmiennych globalnych", która jest widoczna tylko dla tej konkretnej funkcji, gdzie nastąpiła definicja.
Czy takie umieszczenie nie robi z niej jednak globalnej, tak jak te nieszczęsne dwa

nie nie nie nie ... spokojnie na pewno wiedziałeś co robi static albo co zrobiłby dla zmiennej dwa ale pewnie zapomniałeś. Specyfikator static daje tylko powiązanie wewnętrzne czyli zmienna będzie mogła być widoczna TYLKO I WYŁĄCZNIE w ramach tego samego pliku i będziesz miał błąd nawet jak spróbujesz ją wyeksportować przez plik h za pomocą extern - to całkiem oddzielna sytuacja. Wyłączamy widoczność dla innych plików jeśli chodzi o zmienne globalne w pliku jeśli dajemy im static

------------------------ [ Dodano po: 5 minutach ]

Zealota napisał(a):

Może źle rozumiem "sekcja zmiennych globalnych" i nie chodzi tu o miejsce w plikach źródłowych ".c", tylko o miejsce w pamięci?
Dla mnie to miejsce to: "wszędzie" poza funkcjami w plikach źródłowych, a wg dobrych zasad zaraz za includami?

DOBRZE rozumiesz - chodzi o miejsce i widoczność w pliku źródłowym - zaś możliwość powiązań później zależy albo od EXTERN albo od tego co robił roske czyli znowu - reguł "Tentative definitions"

------------------------ [ Dodano po: 6 minutach ]

Quote:

Dlaczego mamy w wyniku 200? Bo dwa z funkcji main() zasłoniła dwa z foo.c?

Bo jednak kompilator połączył obie zmienne "dwa" pod jednym adresem. Udało się to dzięki ? ... "Tentative definitions"

------------------------ [ Dodano po: 10 minutach ]

Zealota napisał(a):

Dlaczego zatem w kolejnym przypadku jest już 2, gdy nie przypiszemy 200 w funkcji main(), bo nagle "wskoczyło" dwa z foo.c

No bo teraz zobacz - a to jest CIEKAWE i dlatego pokazałem taki przypadek

Najpierw wykonuje się funkcja fun1() prawda ? Zmienna "dwa" dzięki (mantra) Tentative definitions - ma ten sam adres a jej inicjalizacja nastąpiła w foo.c i na wartość = 2 zgadza się ? Dlatego zanim nie zmienimy tej wartości to ukazała nam się wartość = 2 ! Następnie w main() przypisując wartość 200 zmieniamy z 2 na 200 bo znowu mamy do czynienia z tym samym adresem w RAM

ale tym przypadkiem chciałem pokazać również koledze roske - jakie głupoty mogą wychodzić podczas analizy kodu - i nie dziwię się, że ty Zealota się dziwisz skąd się wzięło 2 - ale teraz już chyba jasne ?

------------------------ [ Dodano po: 12 minutach ]

Zealota napisał(a):

Ja to zrobiłem, bo nie wytrzymałem . I co bym nie robił, jak nie kombinował, zawsze jest error "multiple definition".
Nawet gdy foo2.c ma tylko jedną linijkę int dwa = 3; .
Zawsze linker się pluje, bo chyba właśnie tak działa, że nie mnoży nie potrzebnych bytów

Jeśli w trzech plikach - ZROBISZ TYLKO jedną inicjalizację to oczywiście zadziała sprawdź to też sobie - warto sprawdzać to na naszym złomie prockowym - bo wtedy człowiek się najwięcej uczy wg mnie

ale też dzięki temu zrozumiesz jak i dlaczego działa Tentative definitions, które kolega roske pomylił sobie z globalnością w całym projekcie - QUNIEC na razie

Statystyki: Napisane przez mirekk36 — 3 paź 2017, o 14:38

Re: Projekt podział na pliki

2017-10-03T14:26:45+01:00

mirekk36 napisał(a):

Zealota napisał(a):

Ta druga przecież wcale nie jest zdefiniowana tylko zadeklarowana

Toż OBYDWIE zmienne o nazwie "dwa" są ZDEFINIOWANE jedna w main.c zaś druga w foo.c - proszę przeczytaj wyżej moje wyjaśnienie

------------------------ [ Dodano po: 1 minucie ]
ale to powiedz od którego momentu ?

No tak walnąlem kulą wpłot. Wracam do przemyśleń na temat definicji i deklaracji

Zealota napisał(a):

choć czytam to i jeszcze nadal nie rozumiem

Nadal to jest takie rozwleczone. Gdzieś dzwoni, ale nie wiadomo gdzie
Powrócę na razie do stwierdzenia:

"Obie są globalne, bo jedną zdefiniowano w main.c, a drugą w foo.c, obie w sekcjach zmiennych globalnych oraz zmienna dwa, poprzez extern, jest widoczna w main.c i jest globalna."
Jednak źle to chyba napisałem, chodziło oczywiście o zmienną jeden, bo to ona ma extern i jest globalna oraz widoczna dla tych co inkludują foo.h.
Zgadza się teraz?

Natomiast dwa jest zmienną globalną, bo umieszczono ją w sekcji zmiennych globalnych pliku foo.c, ale nie jest widoczna dla innych modułów, nawet jeśli includują foo.h, bo nie ma jej deklaracji poprzedzonej extern w pliku foo.h?

Czy może robi się z niej lokalna, bo zabrakło extern i deklaracji w nagłówku foo.h?

A może brak widoczności, pomimo umieszczenia w sekcji zmiennych globalnych, automatycznie robi ze zmiennej lokalną?

A może to po prostu nieporozumienie: umieszczenie w sekcji zmiennych globalnych, ale ograniczenie widoczności powoduje, że ktoś uważa, że jest lokalna?
Taki błąd komunikacyjny?

Co zatem ze zmienną static w jakiejś funkcji.
Piszą, że to jest "zmienna lokalna, ale umieszczona w sekcji zmiennych globalnych", która jest widoczna tylko dla tej konkretnej funkcji, gdzie nastąpiła definicja.
Czy takie umieszczenie nie robi z niej jednak globalnej, tak jak te nieszczęsne dwa

Może źle rozumiem "sekcja zmiennych globalnych" i nie chodzi tu o miejsce w plikach źródłowych ".c", tylko o miejsce w pamięci?
Dla mnie to miejsce to: "wszędzie" poza funkcjami w plikach źródłowych, a wg dobrych zasad zaraz za includami?

Zatem te wyniki, które wspólnie kompilowaliśmy...

Dlaczego mamy w wyniku 200? Bo dwa z funkcji main() zasłoniła dwa z foo.c?
Dlaczego zatem w kolejnym przypadku jest już 2, gdy nie przypiszemy 200 w funkcji main(), bo nagle "wskoczyło" dwa z foo.c

Poczytam jeszcze te wcześniejszy obszerny wywód, ale moje wątpliwości właśnie tu się kumulują, w tych powyższych zdaniach
Co zrobić jak talentu poskąpiło

mirekk36 napisał(a):

Po trzecie - ZAŁÓŻ ŻE PLIK --- FOO1.c i tam zdefiniuj po raz kolejny zmienną dwa - i skompiluj

Ja to zrobiłem, bo nie wytrzymałem . I co bym nie robił, jak nie kombinował, zawsze jest error "multiple definition".
Nawet gdy foo2.c ma tylko jedną linijkę int dwa = 3; .
Zawsze linker się pluje, bo chyba właśnie tak działa, że nie mnoży nie potrzebnych bytów

No chyba, że zamienimy na int dwa; już jest bez błędów hmm....
Taka definicja jest usuwana przez kompilator? Bo nie rezerwuje pamięci i jest ogólnie niepotrzebna? Podobnie jak w przykładzie nr 1 Kolegi roske?
Czy to chodzi o te magiczne 1 vs 4 od Mirka?

Dobra tyle tego dumania...

Statystyki: Napisane przez Zealota — 3 paź 2017, o 14:26

Re: Projekt podział na pliki

2017-10-03T14:18:55+01:00

a teraz roske - co to jest "tentative definition" - to nie jest trudne - także nie jest trudne do przetłumaczenia na polski

Ja bym to nazwał "niepewną definicją" ... albo może lepiej "orientacyjną definicją" ... o co chodzi ?

Otóż ta reguła "tentative definition" wprowadzona do C pozwala na utworzenie wielu definicji tej samej zmiennej i najwyżej jedna z nich posiada jawny inicjalizator. A zatem taki kod:

[syntax=c]int dwa;
int dwa=7;[/syntax]

też się skompiluje dzięki tej regule - co może wydawać się dziwne, ale kompilator C tak "z tyłu zza węgła" łączy wszystkie wstępne definicje w jedną definicję. I masz rację, że zachodzi tu jak pisałeś "tentative definition" ale na ZEUSA no BZDURĄ jest tworzenie definicji o tej samej nazwie i to w różnych plikach ! Co to ma w ogóle wspólnego z pojęciem zmiennych globalnych ?

dla twojej wiadomości:

1. extern int dwa;
2. int dwa;

czym to się różni ? otóż PIERWSZY zapis to DEKLARACJA z linkowaniem zewnętrznym (external linkage)
DRUGI zapis to jest panie DEFINICJA a ta dzięki regułom "tentative definition" jest również z linkowaniem zewnętrznym (external linkage) Dzięki czemu może w ogóle dojść do połączenia definicji zmiennej dwa w twoim przykładzie pod jednym adresem w RAM.

I teraz - jak się spojrzy na taki projekt gdzie będą trzy pliki:

main.c
[syntax=c]int dwa=7; // <---- pierwszy raz w projekcie DEFINICJA zmiennej "dwa"

int main( void ) {
// bla bla bla
}[/syntax]

foo1.c
[syntax=c]int dwa; // <---- drugi raz w projekcie DEFINICJA zmiennej "dwa"

void fun1( void ) {
// bla bla bla
}[/syntax]

foo2.c
[syntax=c]int dwa; // <---- trzeci raz w projekcie DEFINICJA zmiennej "dwa"

void fun1( void ) {
// bla bla bla
}[/syntax]

i w każdym definicja zmiennej o nazwie "dwa" to też się skompiluje dzięki temu mechanizmowi .... ale czy TAK PISZE się programy ? No bój się Pan Boga! ... Ty chcesz używać świadomie "tentative definition" - w KAŻDYM projekcie pisząc tę samą DEFINICJĘ zmiennej ? sorry ale to już wręcz niedorzeczność - owszem to zadziała ale to MEGA BZDURA - tyle że pokazuję ci dlaczego to zadziała

zamiast więc pisać z uporem maniaka - jak sam to określałeś - WYSTARCZY korzystać z PRZEJRZYSTEGO określania zakresu widoczności zmiennych, które mają być GLOBALNE - dla innych plików ... toż wystarczy na ZEUSA tylko w jednym pliku *.h tak jak to zrobiłeś ze zmienną "jeden" użyć extern !

extern int dwa;

czym JASNO określasz zakres widoczności i linkowania tej zmiennej. Widząc to w kodzie - JESTEM nie tylko przekonany, że gdzieś w jednym z np 50-ciu plików projektu znajduje się JEDNA (Qurczę) DEFINICJA zmiennej - która może być również jawnie inicjalizowana ....

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

i na sam KONIEC chłopie teraz o ile nie bawisz się w pisanie kodu w konsoli tylko w jakimś porządnym graficznym środowisku jak ECLIPSE zrób sobie taki mały niewinny super krótki teścik;

Gdy będziesz miał w tych trzech plikach w KAŻDYM definicję "dwa" to spróbuj trzymając wciśnięty LEWY CONTROL plus kliknięcie MYCHĄ - kliknąć na nazwie "dwa" ..... KICHA ! nic się nie stanie bo stoisz niby na definicji - ale tych fantomowych definicji masz aż trzy ?

Za to kliknij sobie w ten sposób na nazwę "jeden" w main.c i zobacz jak ładnie poprowadzi cię środowisko do miejsca gdzie jest DEFINICJA tej zmiennej !

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

jak sobie zrobisz te trzy pliki - to zauważ, że ZAWSZE w pliku w którym będziesz miał inicjalizację zmiennej "dwa" to w objectdumpie zobaczysz

Code:

O .data.dwa

zaś w pozostałych plikach

Code:

O *COM* 00000001 dwa

u mnie tu na końcu będzie jeden a u ciebie 4 - ale jak pisałem wcześniej to zagadka dlaczego ?

------------------------ [ Dodano po: 5 minutach ]

gdzieś znalazłem takie wyjaśnienie:

Quote:

Tentative definitions were invented to standardize various pre-C89 approaches to forward declaring identifiers with internal linkage.

więc kończąc - ma to tyle wspólnego z twoim pojęciem globalności co ... no właśnie co z czym ?

Statystyki: Napisane przez mirekk36 — 3 paź 2017, o 14:18

Re: Projekt podział na pliki

2017-10-03T13:07:21+01:00

roske napisał(a):

...zmienna dwa odzyskuje swoją "globalnowato-alokowalność". Są dwie zmienne globalne, konsolidator nie może tego rozwiązać. Co się stało? Zastosowanie znalazło "tentative definition":

W AVR GCC jak widać to nie zadziała co ci pokazałem i udowodniłem a ty dalej z uporem maniaka dowodzisz swojego - zamiast podchodzić do zmiennych globalnych jak się należy i nie byłoby żadnego problemu jak mówię skompiluj trzeci plik z trzecią definicją tej samej zmiennej - ja nie mam kompilatora C na PC więc nie mam jak sprawdzić - może u ciebie też zadziała

Tyle że NAWET jeśli zadziała to fakt, że kodzie projektu w 40 plikach będziesz miał definicję zmiennej "dwa" - zamiast rozprzestrzeniać jej widoczność za pomocą extern - jest po prostu (delikatnie mówiąc) tragicznym pomysłem na podejście do programowania

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

roske napisał(a):

mirekk36 napisał(a):

korzystamy z różnych kompilatorów

Ja używam GCC. A Ty nie AVR-GCC? ...Czyli GCC.

No i co? dla ciebie nie ma różnic ? pomimo że pokazałem ci objecdumpy ? z AVR ?

Statystyki: Napisane przez mirekk36 — 3 paź 2017, o 13:07