Izvorne datoteke
Tekst C programa može se podijeliti u nekoliko izvornih datoteka. Izvorna datoteka je tekstualna datoteka koja sadrži cijeli program ili njegov dio. Kada kompajlirate izvorni program, svaka od njegovih sastavnih izvornih datoteka mora se prevesti zasebno i zatim povezati s drugim datotekama pomoću povezivača. Zasebne izvorne datoteke mogu se kombinirati u jednu izvornu datoteku, sastaviti kao cjelinu, korištenjem direktive predprocesora #uključiti.
Izvorna datoteka može sadržavati bilo koju potpunu kombinaciju direktiva, instrukcija prevoditelja, deklaracija i definicija. Integritet znači da objekti kao što su definicije funkcija, strukture podataka ili skup povezanih direktiva uvjetne kompilacije moraju biti locirani u cijelosti u jednoj datoteci, odnosno ne mogu započeti u jednoj datoteci, već se nastaviti u drugoj.
Izvorna datoteka ne mora sadržavati izvršne izraze. Ponekad je prikladno smjestiti definicije varijabli u jednu datoteku i koristiti te varijable u drugim datotekama deklarirajući ih. U tom slučaju definicije varijabli postaju lako pretražive i modificirane. Iz istog razloga, imenovane konstante i makronaredbe obično se skupljaju u zasebne datoteke i uključuju putem direktive predprocesora #uključiti na izvorne datoteke koje ih zahtijevaju.
Upute prevoditelja obično se odnose samo na određene dijelove izvorne datoteke. Specifične akcije prevoditelja, određene direktivama, određene su specifičnom implementacijom C prevoditelja.
U sljedećem primjeru, izvorni program se sastoji od dvije izvorne datoteke. Funkcije glavni i maks predstavljeni u zasebnim datotekama. Funkcija glavni koristi funkciju maks u procesu njegovog izvođenja.
/ * izvorna datoteka 1 - glavna funkcija * /
eksterni int max (int, int); / * deklaracija funkcije * /
main () / * definicija funkcije * /
int w = JEDAN, x = DVA, y = TRI;
/ * izvorna datoteka 2 - maksimalna funkcija * /
int max (a, b) / * definicija funkcije * /
U prvoj izvornoj datoteci, funkcija maks deklarirano, ali nedefinirano. Ova deklaracija funkcije naziva se privremenom; omogućuje prevoditelju da kontrolira poziv funkcije prije nego što je definirana. Definicija funkcije glavni sadrži pozive funkcija maks.
Redovi koji počinju s # su direktive pretprocesora. Smjernice govore predprocesoru da zamijeni JEDAN, DVA, TRI identifikatora u prvoj izvornoj datoteci s odgovarajućim vrijednostima. Smjernice nisu obuhvaćene drugom izvornom datotekom.
podrška.microsoft
Kada promijenite izvorne datoteke u Visual C ++ i spremite ih, retke se moraju završiti kombinacijom "CR / LF" [carriage return, line feed]. Na UNIX sustavima, linije se završavaju s "LF". Stoga, kada pregledavate datoteke koje su se promijenile u grupi Windows na UNIX sustavima, možete vidjeti mnogo znakova "^ M" u nizovima. To se događa samo kada uređivač ne zna kako protumačiti Windows datoteku. Visual C ++ može otvarati datoteke u blizini redaka koji završavaju UNIX LF stvaranjem. Ako promijenite ovu datoteku i spremite je iz Visual C ++, ona se sprema u Windows formatu (vidjet ćete CR / LF, a ne LF koji je prethodno bio na sustavu).
Ovaj članak opisuje postupke za spremanje izmijenjene datoteke stvorene na Windows platformi u formatu koji se može koristiti na UNIX sustavima.
BILJEŠKA: Visual C ++.NET IDE sadrži funkcije dostupne za spremanje datoteke u UNIX formatu. U IDE-u spremite datoteku s Spremi kao..., odaberite Spremi s padajućeg popisa Spremi kodiranjem... i pritisnite thrn Da... Odaberite Kodiranje niza s padajućeg popisa UNIX (LF) a zatim kliknite u redu.
Možete koristiti sljedeće korake za stvaranje projekta Win32 konzolne aplikacije koji pretvara datoteku koja sadrži "CR / LF" u završetak reda za "LF":
- Za stvaranje novog praznog projekta pod nazivom DOS2UNIX pomoću Win32 konzolnih aplikacija.
- Iz Datoteka izborniku, pritisnite tipku Novi a zatim kliknite Datoteke Tab.
- Molimo izaberite C / C ++ izvorna datoteka i unesite naziv nove datoteke DOS2UNIX.cpp.
- Zalijepite sljedeći kod u DOS2UNIX.cpp:
#uključiti
#uključiti #uključiti korištenje imenskog prostora std; int main (int argc, char * argv) (if (argc! = 2) (cout<< "Please specify: dos2unix filename" << endl; return 0; } char ch; char temp="\0"; //Open the file for reading in binarymode. ifstream fp_read(argv, ios_base::in \ / ios_base::binary); sprintf(temp, "%s.temp", argv); //Create a temporary file for writing in the binary mode. This //file will be created in the same directory as the input file. ofstream fp_write(temp, ios_base::out \ / ios_base::trunc \ / ios_base::binary); while(fp_read.eof() != true) { fp_read.get(ch); //Check for CR (carriage return) if((int)ch == 0x0D) continue; if (!fp_read.eof())fp_write.put(ch); } fp_read.close(); fp_write.close(); //Delete the existing input file. remove(argv); //Rename the temporary file to the input file. rename(temp, argv); //Delete the temporary file. remove(temp); return 0; } - Iz Zgrada izborniku, pritisnite tipku Stvaranje DOS2UNIX.exe za stvaranje EXE datoteke.
Možda ćete morati provjeriti ovu exe datoteku da vidite radi li ispravno. Da biste to učinili, otvorite datoteku u binarnom uređivaču Visual C ++ Prilikom odabira Otvorena u grupi Datoteka izborniku odabirom DOS2UNIX.ex, Postavka Otvori kao Kome Binarni a zatim kliknite Otvorena... Na primjer, ako datoteka sadrži "hellocrlfworld", datoteka binarnih podataka (heksadecimalna) izgledala bi ovako:
48 65 6 C 6 C 6F 0 D 0A 57 6F 72 6 C 64
Ovo je ekvivalentno:
Hej
Mir
U naredbenom retku pokrenite dos2unix.exe
Ovo se može koristiti zajedno s Visual C ++ modelom automatizacije za automatizaciju cijelog procesa. Jednostavne makronaredbe skripte Microsoft Visual Basic mogu se napisati za pozivanje ovog alata, ali prvo morate dodati ovaj alat Servis meni izgleda ovako:
- Iz Servis izborniku, pritisnite tipku Prilagodba a zatim kliknite Servis Tab.
- Navedite naziv kao što je DOS2UNIX i navedite puni put do datoteke Dos2unix.exe u Tim polje za uređivanje.
- Postavite argument na $ (Filename) $ (FileExt).
- Navedite izvorni direktorij $ (WkspDir) (navedite vlastiti put).
Da biste testirali program, otvorite datoteku u uređivaču Visual C ++, a zatim iz Servis izbornik za pokretanje DOS2UNIX sredstva. Vidjet ćete da su svi CR znakovi iz datoteke otvorene u uređivaču uklonjeni.
Ako trebate automatizirati ovaj proces, postupajte tako da svaki put kada spremate otvorenu datoteku u uređivač Visual C ++, pozove se alat DOS2UNIX.exe za uklanjanje 0x0d s, a zatim upotrijebi sljedeću makronaredbu VBScript:
"Ovaj događaj se pokreće svaki put kada se dokument spremi u VC ++ Editor. Sub Application_DocumentSave (theDocument)" Ovo će pozvati korisnički alat u izborniku Alati. "Promijenite broj ovisno o tome što imate. Prema zadanim postavkama samo vi" imate 6 alata u izborniku Alati, tako da će DOS2UNIX alat biti 7.. Izvrši naredbu "UserTool7" Kraj pod
Ovaj VBScript kod će raditi samo ako imate otvorene datoteke u Visual C++ Editoru. Ovo je jedini način za pozivanje exe datoteke iz VBScript makronaredbe (VBScript makronaredbi se ne mogu proslijediti parametri). Umjesto toga možete upisati i to će biti fleksibilnije. Pozovite alat "DOS2UNIX.exe" iz dodatka bez potrebe da ga dodajete Servis izbornik.
U Visual C ++ pomoću priložene makronaredbe VBScript:
- Otvorite postojeću datoteku s nastavkom .dsm ili je stvorite.
- Zalijepite prethodno navedeni kod u datoteci.
- U Visual C ++ slijedite ove korake.
- Iz Servis izborniku, pritisnite tipku Prilagodba.
- Kliknite gumb Datoteke makronaredbi i dodataka Tab.
- Kliknite gumb Pregled preuzmite .dsm datoteku koja sadrži makronaredbu. Nakon što je .dsm datoteka odabrana u Pregled dijaloškom okviru, datoteka će se pojaviti u Dodaci i makronaredbe popis datoteka pomoću odabranog potvrdnog okvira pokraj njega.
- Kliknite gumb Zatvoriti nastaviti.
Sada ako otvorite datoteku u uređivaču Visual C ++ i spremite iz datoteke Datoteka izbornik koji poziva makro i svi 0x0d s bit će uklonjeni iz otvorene datoteke. Budući da će to utjecati na bilo koju datoteku koju čuvate od sada i primijeniti na bilo koji projekt koji otvorite u budućnosti, svakako onemogućite makronaredbu iz Servis izbornik pomoću Prilagodba(poništite okvir pored makronaredbe).
Ovisno o vašem okruženju izrade (nećete specificirati), možda ćete otkriti da radi točno onako kako želite.
Međutim, postoje mnoga okruženja (i IDE-ovi i mnoge ručno izrađene Makefile) koje čekaju na prevođenje * .c - ako se to dogodi, vjerojatno ćete naići na pogreške povezivača zbog duplih simbola.
U pravilu, ovu praksu treba izbjegavati.
Ako apsolutno morate # uključiti izvor (i općenito ga treba izbjegavati), upotrijebite drugu datoteku za datoteku.
Uključivanje datoteke C u drugu datoteku je legalno, ali nije preporučljivo osim ako ne znate točno zašto to činite i što pokušavate postići.
Prilično sam siguran da ćete, ako ovdje objavite razlog zašto se vaše pitanje priopćava zajednici, pronaći drugi prikladan način da postignete svoj cilj (zabilježite "gotovo" jer bi to moglo biti rješenje s obzirom na kontekst).
Inače, promašio sam drugi dio pitanja. Ako je datoteka C uključena u drugu datoteku i istovremeno uključena u projekt, vjerojatno ćete naići na problem duplih simbola, zašto će povezivanje objekata, odnosno ista funkcija biti definirana dva puta (osim ako nisu statični ).
Jezik C ne zabranjuje ovu vrstu #include, ali rezultirajuća jedinica prijevoda i dalje mora biti valjana C.
Ne znam koji program koristite s .prj datotekom. Ako koristite nešto poput "make" ili Visual Studio ili bilo što drugo, samo provjerite jeste li postavili njegov popis datoteka za sastavljanje bez one koja se ne može sastaviti samostalno.
Možete koristiti gcc prevodilac na linuxu da povežete dvije datoteke s jednim izlazom. Pretpostavimo da imate dvije c datoteke, jedna je "main.c", a druga je "support.c". Dakle, naredba za povezivanje ovo dvoje
Gcc main.c support.c -o main.out
Ove dvije datoteke bit će povezane s istim izlazom main.out. Za pokretanje izlaza, naredba bi bila
./main.out
Ako koristite funkciju main.c koja je deklarirana u datoteci support.c, tada je morate deklarirati u osnovi koristeći klasu extern pohrane.
Ako se pravilno koristi, ovo može biti korisna tehnika.
Pretpostavimo da imate složen podsustav kritičan za misiju s prilično malim javnim sučeljem i puno neimplementiranog implementacionog koda. Kod pokreće do nekoliko tisuća redaka, stotine privatnih funkcija i dosta privatnih podataka. Ako radite s netrivijalnim ugrađenim sustavima, vjerojatno se često suočavate s ovom situacijom.
Vaše rješenje će vjerojatno biti slojevito, modularno i odvojeno, a ti aspekti se mogu prikladno predstaviti i poboljšati kodiranjem različitih dijelova podsustava u različitim datotekama.
S C-om možete izgubiti puno. Gotovo svi alati pružaju pristojne optimizacije za jednu jedinicu kompilacije, ali su vrlo pesimistični u pogledu svega što je eksterno deklarirano.
Ako sve stavite u jedan originalni C modul, dobit ćete -
Poboljšanja performansi i veličine koda - U mnogim slučajevima, pozivi funkcija bit će umetnuti. Čak i bez inlaya, prevodilac ima mogućnost generiranja učinkovitijeg koda.
Podaci i funkcije na razini kanala su skriveni.
Izbjegavanje onečišćenja prostora imena i njegovih posljedica - možete koristiti manje glomazna imena.
Brže sastavljanje i povezivanje.
Ali također dobivate opaki nered kada je u pitanju uređivanje te datoteke i gubite impliciranu modularnost. To se može prevladati dijeljenjem izvornog koda u više datoteka i uključivanjem u jednu jedinicu kompilacije.
Međutim, morate primijeniti neke konvencije da biste to riješili. To će do neke mjere ovisiti o vašem lancu alata, ali neki opći smjernici su -
Stavite javno sučelje u zasebnu datoteku zaglavlja - to biste ipak trebali učiniti.
Imajte jednu glavnu .c datoteku koja uključuje sve podređene .c datoteke. Također može uključivati kod za otvoreno sučelje.
Koristite zaštitu kompajlera tako da privatna zaglavlja i izvorne jedinice ne budu uključene u vanjske jedinice kompilacije.
Svi osobni podaci i funkcije moraju se proglasiti statičnima.
Održavajte konceptualnu razliku između .c i .h datoteka. Koristi postojeće konvencije. Razlika je u tome što ćete u svojim naslovima imati puno statičnih oglasa.
Osim ako vaš lanac alata ne nameće bilo kakav razlog, ne biste trebali navoditi privatne implementacijske datoteke kao .c i .h. Ako koristite uključene štitnike, oni neće generirati kod i neće unijeti nova imena (kao rezultat toga, možete naići na neke prazne segmente). Velika prednost je u tome što će drugi alati (poput IDE-a) postupati s tim datotekama na odgovarajući način.
Ekstenzija datoteke je irelevantna za većinu C prevoditelja, pa će raditi.
Međutim, ovisno o postavkama vaše datoteke ili projekta, uključena c datoteka može generirati zasebnu objektnu datoteku. Kada se poveže, to može rezultirati dvostruko definiranim znakovima.
trebali biste dodati ovakav naslov
#uključiti
Napomena: obje datoteke moraju biti na istom mjestu
Možete ispravno uključiti .C ili .CPP datoteke u druge izvorne datoteke. Ovisno o vašem IDE-u, obično možete spriječiti dvostruko uvezivanje gledanjem svojstava izvornih datoteka koje želite uključiti, obično desnim klikom na njih i klikom na svojstva, te poništavanjem / kvačicom compile / link / exclude from assembly ili bilo koje druge opcija... može biti. Ili ne možete uključiti datoteku u sam projekt, tako da IDE niti ne zna da postoji i neće je pokušati kompajlirati. A kod make-datoteka jednostavno niste stavili datoteku u nju radi kompilacije i povezivanja.
EDIT: Oprostite, dao sam odgovor umjesto ostalih odgovora :(
Slično pitanje nedavno mi je postavio kolega koji počinje programirati na C jeziku. I mislio sam da je ovo dobar razlog da podijelim svoje razumijevanje ovog problema. Jer čak ni iskusni programeri nemaju uvijek ista stajališta o ovom pitanju.
Ovo je dijelom i stvar ukusa, pa koga zanima kako ja to radim, dobrodošao u mačku.
Unatoč činjenici da je "cijela istina" o h-datotekama sadržana u odgovarajućem odjeljku opisa gcc predprocesora, dopustiti ću si neka objašnjenja i ilustracije.
Dakle, doslovno, datoteka zaglavlja (h-datoteka) je datoteka koja sadrži C deklaracije i makro definicije namijenjena upotrebi u nekoliko izvornih datoteka (c-datoteka). Ilustrirajmo ovo.
Lako je vidjeti da se funkcije 1 i 2, kao i makro 2, spominju u obje datoteke. A budući da uključivanje datoteka zaglavlja daje iste rezultate kao kopiranje sadržaja u svaku C datoteku, možemo učiniti sljedeće: 
Stoga smo jednostavno odabrali zajednički dio iz dvije datoteke i smjestili ga u datoteku zaglavlja.
Ali je li datoteka zaglavlja u ovom slučaju sučelje?
- Ako trebamo koristiti funkcionalnost koju funkcije 1 i 2 implementiraju negdje drugdje, onda Da
- Ako je makronaredba 2 namijenjena samo za korištenje u datotekama Unit1.c i Unit2.c, tada nema mjesta u datoteci sučelja
Odgovor na ovo pitanje ovisi o detaljima implementacije funkcija sučelja i o tome gdje su implementirane. Na primjer, ako dijagrame učinite detaljnijim, možete zamisliti varijantu kada se funkcije sučelja implementiraju u različite datoteke:
Ova implementacija dovodi do visoke kohezije koda, niske mogućnosti testiranja i poteškoća u ponovnoj upotrebi takvih modula.
Kako ne bih imao takvih poteškoća, C-datoteku i datoteku zaglavlja uvijek smatram jednim modulom. U kojem,
- datoteka zaglavlja sadrži samo one deklaracije funkcija, tipova, makronaredbi koje su dio sučelja ovog modula.
- C-datoteka, zauzvrat, mora sadržavati implementaciju svih funkcija deklariranih u h-datoteci, kao i privatne tipove, makronaredbe i funkcije koje su potrebne za implementaciju sučelja.
Dijagram pokazuje da zapravo imamo posla s dva nezavisna modula, od kojih svaki ima svoje sučelje u obliku datoteke zaglavlja. To omogućuje korištenje samo sučelja koje je stvarno potrebno u ovom konkretnom slučaju, a ovi moduli se mogu testirati neovisno jedan o drugom.
Čitatelj je možda primijetio da se makro 2 iz datoteke zaglavlja ponovno vratio kao kopija u obje C-datoteke. Naravno, ovo nije baš zgodno za održavanje. No, također nije ispravno napraviti ovaj makro dio sučelja.
U takvim slučajevima radije napravim zasebnu datoteku zaglavlja koja sadrži vrste i makronaredbe potrebne za više C datoteka.
Nadam se da sam uspio identificirati one entitete koje je potrebno smjestiti u datoteke zaglavlja. Također, da se pokaže razlika između sučelja i datoteka koje sadrže deklaracije i makronaredbe koje zahtijeva nekoliko C-datoteka.
Hvala vam na pažnji prema materijalu.
glasajte online (8)
Uključivanje datoteke C u drugu datoteku je legalno, ali nije preporučljivo osim ako ne znate točno zašto to činite i što pokušavate postići.
Prilično sam siguran da ćete, ako ovdje objavite razlog zašto se vaše pitanje priopćava zajednici, pronaći drugi prikladan način da postignete svoj cilj (zabilježite "gotovo" jer bi to moglo biti rješenje s obzirom na kontekst).
Inače, promašio sam drugi dio pitanja. Ako je datoteka C uključena u drugu datoteku i istovremeno uključena u projekt, vjerojatno ćete naići na problem duplih simbola, zašto će povezivanje objekata, odnosno ista funkcija biti definirana dva puta (osim ako nisu statični ).
Ekstenzija datoteke je irelevantna za većinu C prevoditelja, pa će raditi.
Međutim, ovisno o postavkama vaše datoteke ili projekta, uključena c datoteka može generirati zasebnu objektnu datoteku. Kada se poveže, to može rezultirati dvostruko definiranim znakovima.
Ovisno o vašem okruženju izrade (nećete specificirati), možda ćete otkriti da radi točno onako kako želite.
Međutim, postoje mnoga okruženja (i IDE-ovi i mnoge ručno izrađene Makefile) koje čekaju na prevođenje * .c - ako se to dogodi, vjerojatno ćete naići na pogreške povezivača zbog duplih simbola.
U pravilu, ovu praksu treba izbjegavati.
Ako apsolutno morate # uključiti izvor (i općenito ga treba izbjegavati), upotrijebite drugu datoteku za datoteku.
Možete koristiti gcc prevodilac na linuxu da povežete dvije datoteke s jednim izlazom. Pretpostavimo da imate dvije c datoteke, jedna je "main.c", a druga je "support.c". Dakle, naredba za povezivanje ovo dvoje
Gcc main.c support.c -o main.out
Ove dvije datoteke bit će povezane s istim izlazom main.out. Za pokretanje izlaza, naredba bi bila
./main.out
Ako koristite funkciju main.c koja je deklarirana u datoteci support.c, tada je morate deklarirati u osnovi koristeći klasu extern pohrane.
Mislio sam podijeliti situaciju u kojoj je moj tim odlučio uključiti .c datoteke. Naš arhitekt se uglavnom sastoji od modula koji su odvojeni putem sustava za razmjenu poruka. Ovi rukovatelji porukama su javni i pozivaju mnoge lokalne statičke radničke funkcije kako bi obavile svoj posao. Problem se pojavio kada smo pokušali dobiti pokrivenost za naše pojedinačne testne slučajeve, jer je jedini način implementacije ovog privatnog implementacijskog koda bio neizravno putem zajedničkog sučelja za razmjenu poruka. S nekim koljenima radnika u hrpi, ovo se pokazalo kao noćna mora za osiguranje odgovarajuće pokrivenosti.
Uključujući .c datoteke dali su nam mogućnost da dođemo do zupčanika u automobilu, bili smo zainteresirani za testiranje.
Jezik C ne zabranjuje ovu vrstu #include, ali rezultirajuća jedinica prijevoda i dalje mora biti valjana C.
Ne znam koji program koristite s .prj datotekom. Ako koristite nešto poput "make" ili Visual Studio ili bilo što drugo, samo provjerite jeste li postavili njegov popis datoteka za sastavljanje bez one koja se ne može sastaviti samostalno.
Ako se pravilno koristi, ovo može biti korisna tehnika.
Pretpostavimo da imate složen podsustav kritičan za misiju s prilično malim javnim sučeljem i puno neimplementiranog implementacionog koda. Kod pokreće do nekoliko tisuća redaka, stotine privatnih funkcija i dosta privatnih podataka. Ako radite s netrivijalnim ugrađenim sustavima, vjerojatno se često suočavate s ovom situacijom.
Vaše rješenje će vjerojatno biti slojevito, modularno i odvojeno, a ti aspekti se mogu prikladno predstaviti i poboljšati kodiranjem različitih dijelova podsustava u različitim datotekama.
S C-om možete izgubiti puno. Gotovo svi alati pružaju pristojne optimizacije za jednu jedinicu kompilacije, ali su vrlo pesimistični u pogledu svega što je eksterno deklarirano.
Ako sve stavite u jedan originalni C modul, dobit ćete -
Poboljšanja performansi i veličine koda - U mnogim slučajevima, pozivi funkcija bit će umetnuti. Čak i bez inlaya, prevodilac ima mogućnost generiranja učinkovitijeg koda.
Podaci i funkcije na razini kanala su skriveni.
Izbjegavanje onečišćenja prostora imena i njegovih posljedica - možete koristiti manje glomazna imena.
Brže sastavljanje i povezivanje.
Ali također dobivate opaki nered kada je u pitanju uređivanje te datoteke i gubite impliciranu modularnost. To se može prevladati dijeljenjem izvornog koda u više datoteka i uključivanjem u jednu jedinicu kompilacije.
Međutim, morate primijeniti neke konvencije da biste to riješili. To će do neke mjere ovisiti o vašem lancu alata, ali neki opći smjernici su -
Stavite javno sučelje u zasebnu datoteku zaglavlja - to biste ipak trebali učiniti.
Imajte jednu glavnu .c datoteku koja uključuje sve podređene .c datoteke. Također može uključivati kod za otvoreno sučelje.
Koristite zaštitu kompajlera tako da privatna zaglavlja i izvorne jedinice ne budu uključene u vanjske jedinice kompilacije.
Svi osobni podaci i funkcije moraju se proglasiti statičnima.
Održavajte konceptualnu razliku između .c i .h datoteka. Koristi postojeće konvencije. Razlika je u tome što ćete u svojim naslovima imati puno statičnih oglasa.
Osim ako vaš lanac alata ne nameće bilo kakav razlog, ne biste trebali navoditi privatne implementacijske datoteke kao .c i .h. Ako koristite uključene štitnike, oni neće generirati kod i neće unijeti nova imena (kao rezultat toga, možete naići na neke prazne segmente). Velika prednost je u tome što će drugi alati (poput IDE-a) postupati s tim datotekama na odgovarajući način.
Ovo je u redu? da će se sastaviti
je li preporučljivo? no - .c datoteke se kompiliraju u .obj datoteke koje su povezane nakon kompilacije (od strane povezivača) u izvršnu datoteku (ili biblioteku), tako da nema potrebe za uključivanjem jedne .c datoteke u drugu. Umjesto toga, najvjerojatnije biste željeli napraviti .h datoteku koja navodi funkcije/varijable dostupne u drugoj .c datoteci i uključiti .h datoteku
