Skedarët burimor
Teksti i një programi C mund të ndahet në disa skedarë burim. Një skedar burimor është një skedar teksti që përmban ose të gjithë programin ose një pjesë të tij. Kur përpiloni një program burimor, secili prej skedarëve burimor përbërës të tij duhet të përpilohet veçmas dhe më pas të lidhet me skedarë të tjerë nga një lidhës. Skedarët burim të veçantë mund të kombinohen në një skedar të vetëm burimi të përpiluar si një njësi e vetme duke përdorur direktivën e paraprocesorit #përfshi.
Një skedar burim mund të përmbajë çdo kombinim të qëndrueshëm të direktivave, sugjerimeve për përpiluesin, deklaratave dhe përkufizimeve. Integriteti do të thotë që objekte të tilla si përkufizimet e funksioneve, strukturat e të dhënave ose një grup direktivash përpilimi të kushtëzuar duhet të vendosen plotësisht në një skedar, domethënë, ato nuk mund të fillojnë në një skedar dhe të vazhdojnë në një skedar tjetër.
Skedari burimor nuk duhet të përmbajë deklarata të ekzekutueshme. Ndonjëherë është e përshtatshme të vendosni përkufizime të variablave në një skedar, dhe në skedarë të tjerë të përdorni këto variabla duke i deklaruar ato. Në këtë rast, përkufizimet e variablave bëhen lehtësisht të kërkueshme dhe të modifikueshme. Për të njëjtat arsye, konstantet e emërtuara dhe përkufizimet makro zakonisht mblidhen në skedarë të veçantë dhe përfshihen duke përdorur direktivën e paraprocesorit #përfshi te skedarët burim që i kërkojnë ato.
Udhëzimet e përpiluesit zakonisht zbatohen vetëm për seksione të caktuara të skedarit burim. Veprimet specifike të përpiluesit të specifikuara nga këshillat përcaktohen nga zbatimi specifik i përpiluesit C.
Në shembullin e mëposhtëm, programi burim përbëhet nga dy skedarë burim. Funksione kryesore dhe maksimumi paraqitur në dosje të veçanta. Funksioni kryesore përdor funksionin maksimumi gjatë zbatimit të tij.
/* skedari burimor 1 - funksioni kryesor */
extern int max (int, int); /* deklarata e funksionit */
main() /* përcaktimi i funksionit */
int w = NJË, x = DY, y = TRE;
/* skedari burimor 2 - funksioni maksimal */
int max (a, b) /* përcaktimi i funksionit */
Në skedarin e parë burimor, funksioni maksimumi të deklaruara por jo të përcaktuara. Një deklaratë e tillë funksioni quhet deklaratë e përparme; ai lejon kompajlerin të kontrollojë thirrjen e një funksioni përpara se ai të përcaktohet. Përkufizimi i funksionit kryesore përmban thirrje funksionesh maksimumi.
Linjat që fillojnë me # janë direktiva paraprocesoresh. Direktivat i thonë paraprocesorit të zëvendësojë identifikuesit ONE, TWO, THREE në skedarin e parë burimor me vlerat përkatëse. Objekti i direktivave nuk shtrihet në skedarin e dytë burimor.
mbështetje.microsoft
Kur redaktoni skedarët burim në Visual C++ dhe i ruani, rreshtat duhet të përfundojnë me kombinimin e karaktereve "CR/LF" [carriage kthim, furnizim linja]. Në sistemet UNIX, linjat përfundojnë me "LF". Prandaj, kur shikoni skedarë që janë modifikuar në grupin Windows në sistemet UNIX, shumë karaktere "^M" mund të shfaqen në rreshta. Kjo ndodh vetëm kur përdorni një redaktues që nuk di të interpretojë skedarin e Windows. Visual C++ mund të hapë skedarë që kanë rreshta që përfundojnë me krijimin e UNIX LF. Nëse e modifikoni këtë skedar dhe e ruani nga Visual C++, atëherë ai ruhet në formatin Windows (do të shihni CR/LF dhe jo LF që ishte më parë në sistem).
Ky artikull përshkruan procedurat për ruajtjen e një skedari të modifikuar të krijuar në platformën Windows në një format që mund të përdoret në sistemet UNIX.
SHËNIM: Visual C++ .NET IDE përmban funksione të disponueshme për ruajtjen e një skedari në formatin UNIX. Në IDE, ruani skedarin me Ruaje si..., zgjidhni ruaj nga lista rënëse Ruaj me kodim..., dhe shtypni butonin thrn po. Zgjidhni nga lista rënëse Kodimi i vargut UNIX (LF), dhe më pas klikoni butonin Ne rregull.
Ju mund të përdorni hapat e mëposhtëm për të krijuar një projekt aplikacioni të konsolës Win32 që konverton një skedar që përmban "CR/LF" në fundin e rreshtit për "LF":
- Për të krijuar një të ri duke përdorur aplikacionet e konsolës Win32, një projekt bosh me emrin DOS2UNIX.
- Nga Skedari menu, shtypni butonin I ri, dhe më pas klikoni butonin Skedarët skedën.
- Zgjidhni Skedari burim C/C++ dhe shkruani emrin e skedarit të ri DOS2UNIX.cpp.
- Ngjitni kodin e mëposhtëm në DOS2UNIX.cpp:
#përfshi
#përfshi #përfshi duke përdorur hapësirën e emrave 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; } - Nga Ndërtesa menu, shtypni butonin Krijo DOS2UNIX.exe për të krijuar një skedar EXE.
Ju mund të keni nevojë të provoni këtë skedar exe për të parë nëse funksionon siç duhet. Për ta bërë këtë, hapni skedarin në Visual C++ Binary Editor. Nëse zgjidhni Hapur në një grup Skedari menu duke zgjedhur DOS2UNIX.ex, Cilësimet Hapur si Kujt Binar, dhe më pas klikoni Hapur. Për shembull, nëse skedari përmban "hellocrlfworld", të dhënat binare (heksadecimal) do të duken kështu:
48 65 6 C 6 C 6F 0 D 0A 57 6F 72 6 C 64
Kjo është e barabartë me:
Përshëndetje
Botë
Drejtoni komandën dos2unix.exe nga linja e komandës
Ju mund ta përdorni këtë në lidhje me Modelet e Automatizimit Visual C++ për të automatizuar të gjithë procesin. Një skrip i thjeshtë makro Microsoft Visual Basic mund të shkruhet për të thirrur këtë mjet, por fillimisht duhet të shtoni këtë mjet Shërbimi menuja duket si kjo:
- Nga Shërbimi menu, shtypni butonin Vendosja, dhe më pas klikoni butonin Shërbimi skedën.
- Specifikoni një emër, të tillë si DOS2UNIX, dhe specifikoni rrugën e plotë për në Dos2unix.exe në Ekipi fushë redaktimi.
- Vendosni argumentin në $(Emri i skedarit)$(FileExt).
- Specifikoni direktorinë e burimit $(WkspDir) (specifikoni rrugën tuaj).
Për të testuar programin, hapni skedarin në redaktuesin Visual C++ dhe më pas nga Shërbimi menuja e nisjes DOS2UNIX do të thotë. Do të shihni se skedari i hapur në redaktues i janë hequr të gjitha karakteret CR.
Nëse dëshironi të automatizoni këtë proces në mënyrë që sa herë që ruani një skedar të hapur në redaktuesin Visual C++, mjeti DOS2UNIX.exe thirret për të hequr 0x0d s, atëherë përdorni makro VBScript vijues:
"Kjo ngjarje aktivizohet sa herë që dokumenti ruhet në Redaktuesin VC++. Nën Application_DocumentSave(theDocument) "Kjo do të thërrasë veglën e përdoruesit në menynë Vegla. "Ndrysho numrin në varësi të asaj që ke. Si parazgjedhje ju "keni vetëm 6 vegla nën menynë Vegla, kështu që mjeti DOS2UNIX do të jetë i 7-ti. ExecuteCommand "UserTool7" Fund Sub
Ky kod VBScript do të funksionojë vetëm nëse keni skedarë të hapur në Redaktuesin Visual C++. Kjo është mënyra e vetme për të thirrur një skedar .exe nga një makro VBScript (makrove VBScript nuk mund të kalojnë parametrat). Në vend të kësaj mund të shkruani dhe do të jetë më fleksibël. Thirrni mjetin "DOS2UNIX.exe" nga shtesa pa pasur nevojë ta shtoni Shërbimi menu.
Në Visual C++ duke përdorur makron e dhënë VBScript:
- Hapni një skedar ekzistues .dsm ose krijoni një të tillë.
- Ngjitni kodin që keni dhënë më parë në skedar.
- Në Visual C++, bëni sa më poshtë.
- Nga Shërbimi menu, shtypni butonin Vendosja.
- Klikoni butonin Makro dhe skedarë shtesë skedën.
- Klikoni butonin Rishikimi ngarkoni skedarin .dsm që përmban makro. Pasi në dosjen .dsm u zgjodh në Rishikimi kutia e dialogut, skedari do të shfaqet në Shtesa dhe makro listën e skedarëve me kutinë e zgjedhur pranë saj.
- Klikoni butonin mbyll për të vazhduar.
Tani, nëse hapni skedarin në redaktuesin Visual C++ dhe ruani nga skedari Skedari menyja, makroja e thirrur dhe të gjitha 0x0d s do të hiqen nga skedari i hapur. Meqenëse kjo do të ndikojë në çdo skedar të ruajtur tani e tutje dhe të aplikuar në çdo projekt që hapni në të ardhmen, sigurohuni që të çaktivizoni makro nga Shërbimi menu me Vendosja(zgjidh kutinë pranë makros).
Në varësi të mjedisit tuaj të ndërtimit (nuk do ta specifikoni) mund të gjeni se funksionon saktësisht ashtu siç dëshironi.
Megjithatë, ka shumë mjedise (si IDE ashtu edhe shumë skedarë të punuar me dorë) që presin që *.c të kompilohet - nëse kjo ndodh, ka të ngjarë të hasni në gabime lidhëse për shkak të dyfishimit të simboleve.
Si rregull i përgjithshëm, kjo praktikë duhet të shmanget.
Nëse absolutisht duhet # të përfshini burimin (dhe në përgjithësi duhet të shmanget), përdorni një skedar tjetër për skedarin.
Përfshirja e një skedari C në një skedar tjetër është e ligjshme, por jo e këshillueshme nëse nuk e dini saktësisht pse po e bëni atë dhe çfarë po përpiqeni të arrini.
Jam shumë i sigurt që nëse postoni këtu arsyen pse pyetja juaj po raportohet në komunitet, do të gjeni një mënyrë tjetër të përshtatshme për të përmbushur qëllimin tuaj (vini re "pothuajse" pasi është e mundur që kjo të jetë një zgjidhje, duke pasur parasysh kontekstin ).
Meqë ra fjala, e humba pjesën e dytë të pyetjes. Nëse skedari C përfshihet në një skedar tjetër dhe përfshihet në projekt në të njëjtën kohë, ndoshta do të hasni në problemin e dublikimit të simboleve, pse lidhja e objektit, d.m.th. i njëjti funksion do të përcaktohet dy herë (përveç nëse ato janë statike).
Gjuha C nuk e ndalon një lloj të tillë #include, por njësia e përkthimit që rezulton duhet të jetë ende një C e vlefshme.
Nuk e di se çfarë programi po përdorni me skedarin .prj. Nëse jeni duke përdorur diçka si "make" ose Visual Studio ose çfarëdo tjetër, thjesht sigurohuni që ta vendosni në një listë skedarësh që duhet të përpilohen pa një që nuk mund të përpilohet në mënyrë të pavarur.
Ju mund të përdorni përpiluesin gcc në linux për të lidhur dy skedarë në një dalje. Supozoni se keni dy skedarë c, njëri është "main.c" dhe tjetri është "support.c". Pra komanda për të lidhur këto të dyja
gcc kryesore.c mbështetje.c -o kryesore.jashtë
Këta dy skedarë do të lidhen me një dalje main.out. Për të ekzekutuar daljen komanda do të ishte
./kryesore.jashtë
Nëse përdorni funksionin main.c i cili është deklaruar në skedarin support.c, atëherë duhet ta deklaroni atë në main gjithashtu duke përdorur klasën e ruajtjes së jashtme.
Nëse përdoret si duhet, kjo mund të jetë një teknikë e dobishme.
Supozoni se keni një nënsistem kritik të misionit kompleks me një ndërfaqe publike mjaft të vogël dhe shumë kode zbatimi të pazbatuar. Kodi funksionon deri në disa mijëra rreshta, qindra funksione private dhe mjaft të dhëna private. Nëse jeni duke punuar me sisteme të ngulitura jo të parëndësishme, me siguri përballeni me këtë situatë mjaft shpesh.
Zgjidhja juaj ka të ngjarë të jetë e shtresuar, modulare dhe e shkëputur, dhe këto aspekte mund të përfaqësohen dhe përmirësohen me lehtësi duke koduar pjesë të ndryshme të nënsistemit në skedarë të ndryshëm.
Me C, ju mund të humbni shumë duke bërë këtë. Pothuajse të gjitha mjetet ofrojnë optimizime të mira për një njësi të vetme përpilimi, por janë shumë pesimistë për çdo gjë të deklaruar të jashtme.
Nëse vendosni gjithçka në një modul të burimit C, ju merrni -
Përmirësime të performancës dhe madhësisë së kodit - në shumë raste thirrjet e funksionit do të jenë të lidhura. Edhe pa inlining, përpiluesi ka hapësirë për të gjeneruar kod më efikas.
Të dhënat dhe funksionet e nivelit të kanalit janë të fshehura.
Shmangia e ndotjes së hapësirës së emrave dhe përfundimi i saj është se ju mund të përdorni emra më pak të rëndë.
Kompilim dhe lidhje më të shpejtë.
Por ju gjithashtu merrni një rrëmujë të pahijshme kur bëhet fjalë për redaktimin e atij skedari dhe humbni modularitetin e synuar. Kjo mund të tejkalohet duke ndarë kodin burimor në skedarë të shumtë dhe duke i përfshirë ato në një njësi të vetme përpilimi.
Megjithatë, ju duhet të impononi disa konventa për ta trajtuar këtë. Në një farë mase kjo do të varet nga zinxhiri juaj i veglave, por disa tregues të përgjithshëm janë
Vendosni ndërfaqen publike në një skedar të veçantë kokë - duhet ta bëni gjithsesi.
Keni një skedar kryesor .c që përfshin të gjithë skedarët .c të fëmijës. Mund të përfshijë gjithashtu kodin për ndërfaqen publike.
Përdorni mbrojtëse përpiluesi për të parandaluar përfshirjen e kokave private dhe moduleve burimore nga modulet e jashtme të përpilimit.
Të gjitha të dhënat dhe funksionet private duhet të deklarohen statike.
Mbani një dallim konceptual midis skedarëve .c dhe .h. Ai përdor konventat ekzistuese. Dallimi është se do të keni shumë reklama statike në titujt tuaj.
Nëse zinxhiri juaj i veglave nuk ka kuptim, nuk duhet të specifikoni skedarë privatë të zbatimit si .c dhe .h. Nëse përdorni rojet e përfshira, ato nuk do të gjenerojnë kod dhe nuk do të prezantojnë asnjë emër të ri (mund të përfundoni me disa segmente boshe si rezultat). Avantazhi i madh është se mjetet e tjera (p.sh. IDE) do t'i përpunojnë këto skedarë në përputhje me rrethanat.
Zgjatja e skedarit nuk ka rëndësi për shumicën e përpiluesve C, kështu që do të funksionojë.
Megjithatë, në varësi të skedarit tuaj ose cilësimeve të projektit, skedari c i përfshirë mund të gjenerojë një skedar objekti të veçantë. Kur lidhni, kjo mund të rezultojë në dyfishimin e karaktereve të caktuara.
ju duhet të shtoni një titull si ky
#përfshi
Shënim: të dy skedarët duhet të vendosen në të njëjtin vend
Ju mund të përfshini siç duhet skedarët .C ose .CPP në skedarë të tjerë burimor. Në varësi të IDE-së tuaj, zakonisht mund të parandaloni lidhjen e dyfishtë duke parë vetitë e skedarëve burimor që dëshironi të përfshini, zakonisht duke klikuar me të djathtën mbi to dhe duke klikuar mbi pronat, dhe hiqni zgjedhjen/kontrolloni përpilimin/lidhjen/përjashtimin nga ndërtimi ose çfarëdo tjetër. ndoshta. Ose nuk mund ta përfshini skedarin në vetë projektin, kështu që IDE as nuk e di se ekziston dhe nuk do të përpiqet ta përpilojë atë. Dhe me skedarët e krijuar, thjesht nuk keni vendosur një skedar në të për ta përpiluar dhe lidhur.
EDIT: Më falni që dhashë një përgjigje në vend që t'u përgjigjem përgjigjeve të tjera :(
Një pyetje të ngjashme më bëri së fundmi një koleg që po fillon të programojë në gjuhën C. Dhe mendova se ky është një rast i mirë për të ndarë kuptimin tim për këtë çështje. Sepse edhe programuesit me përvojë nuk kanë gjithmonë pikëpamje të ngjashme për këtë çështje.
Kjo është pjesërisht një çështje shije, kështu që nëse dikush është i interesuar se si e bëj këtë, mirëpresim nën cat.
Megjithëse "e gjithë e vërteta" për skedarët h gjendet në seksionin përkatës të përshkrimit të paraprocesorit gcc, unë do t'i lejoj vetes disa shpjegime dhe ilustrime.
Pra, fjalë për fjalë, një skedar me kokë (skedar h) është një skedar që përmban deklarata C dhe përkufizime makro të destinuara për t'u përdorur në skedarë të shumëfishtë burimesh (skedarë c). Le ta ilustrojmë këtë.
Është e lehtë të shihet se funksionet 1 dhe 2, si dhe makro 2, përmenden në të dy skedarët. Dhe, meqenëse përfshirja e skedarëve të kokës ka të njëjtat rezultate si kopjimi i përmbajtjes në çdo skedar C, ne mund të bëjmë sa më poshtë: 
Kështu, ne thjesht zgjodhëm pjesën e përbashkët nga dy skedarët dhe e vendosëm në skedarin e kokës.
Por a është skedari i kokës një ndërfaqe në këtë rast?
- Nëse duhet të përdorim funksionalitetin që funksionet 1 dhe 2 zbatojnë diku tjetër, atëherë Po
- Nëse makro 2 është menduar vetëm për përdorim në skedarët Unit1.c dhe Unit2.c, atëherë ai nuk ka vend në skedarin e ndërfaqes
Përgjigja për këtë pyetje varet nga detajet e zbatimit të funksioneve të ndërfaqes dhe nga ku ato zbatohen. Për shembull, nëse i bëni diagramet më të detajuara, mund të imagjinoni rastin kur funksionet e ndërfaqes zbatohen në skedarë të ndryshëm:
Ky opsion implementimi çon në kohezion të lartë të kodit, testueshmëri të ulët dhe vështirësi në ripërdorimin e moduleve të tilla.
Për të mos pasur vështirësi të tilla, unë gjithmonë e trajtoj skedarin C dhe skedarin e kokës si një modul. Ku,
- skedari i kokës përmban vetëm ato deklarata të funksioneve, llojeve, makrove që janë pjesë e ndërfaqes së këtij moduli.
- Skedari C, nga ana tjetër, duhet të përmbajë zbatimin e të gjitha funksioneve të deklaruara në skedarin h, si dhe llojet private, makrot dhe funksionet që nevojiten për të zbatuar ndërfaqen.
Nga diagrami shihet se në fakt kemi të bëjmë me dy module të pavarura, secila prej të cilave ka ndërfaqen e vet në formën e një skedari kokë. Kjo bën të mundur përdorimin e vetëm ndërfaqes që është realisht e nevojshme në këtë rast të veçantë.Për më tepër, këto module mund të testohen në mënyrë të pavarur nga njëri-tjetri.
Lexuesi mund të ketë vënë re se makro 2 nga skedari i kokës është kthyer si kopje në të dy skedarët C. Sigurisht, kjo nuk është shumë e përshtatshme për t'u ruajtur. Por ta bësh këtë makro pjesë të ndërfaqes nuk është e saktë.
Në raste të tilla, unë preferoj të krijoj një skedar të veçantë të kokës që përmban llojet dhe makrot që nevojiten nga disa skedarë C.
Shpresoj se kam qenë në gjendje të identifikoj ato entitete që duhet të vendosen në skedarët e kokës. Dhe gjithashtu, për të treguar ndryshimin midis ndërfaqeve dhe skedarëve që përmbajnë deklarata dhe makro të nevojshme nga disa skedarë C.
Faleminderit për vëmendjen tuaj ndaj materialit.
votoni në internet (8)
Përfshirja e një skedari C në një skedar tjetër është e ligjshme, por jo e këshillueshme nëse nuk e dini saktësisht pse po e bëni atë dhe çfarë po përpiqeni të arrini.
Jam shumë i sigurt që nëse postoni këtu arsyen pse pyetja juaj po raportohet në komunitet, do të gjeni një mënyrë tjetër të përshtatshme për të përmbushur qëllimin tuaj (vini re "pothuajse" pasi është e mundur që kjo të jetë një zgjidhje, duke pasur parasysh kontekstin ).
Meqë ra fjala, e humba pjesën e dytë të pyetjes. Nëse skedari C përfshihet në një skedar tjetër dhe përfshihet në projekt në të njëjtën kohë, ndoshta do të hasni në problemin e dublikimit të simboleve, pse lidhja e objektit, d.m.th. i njëjti funksion do të përcaktohet dy herë (përveç nëse ato janë statike).
Zgjatja e skedarit nuk ka rëndësi për shumicën e përpiluesve C, kështu që do të funksionojë.
Megjithatë, në varësi të skedarit tuaj ose cilësimeve të projektit, skedari c i përfshirë mund të gjenerojë një skedar objekti të veçantë. Kur lidhni, kjo mund të rezultojë në dyfishimin e karaktereve të caktuara.
Në varësi të mjedisit tuaj të ndërtimit (nuk do ta specifikoni) mund të gjeni se funksionon saktësisht ashtu siç dëshironi.
Megjithatë, ka shumë mjedise (si IDE ashtu edhe shumë skedarë të punuar me dorë) që presin që *.c të kompilohet - nëse kjo ndodh, ka të ngjarë të hasni në gabime lidhëse për shkak të dyfishimit të simboleve.
Si rregull i përgjithshëm, kjo praktikë duhet të shmanget.
Nëse absolutisht duhet # të përfshini burimin (dhe në përgjithësi duhet të shmanget), përdorni një skedar tjetër për skedarin.
Ju mund të përdorni përpiluesin gcc në linux për të lidhur dy skedarë në një dalje. Supozoni se keni dy skedarë c, njëri është "main.c" dhe tjetri është "support.c". Pra komanda për të lidhur këto të dyja
gcc kryesore.c mbështetje.c -o kryesore.jashtë
Këta dy skedarë do të lidhen me një dalje main.out. Për të ekzekutuar daljen komanda do të ishte
./kryesore.jashtë
Nëse përdorni funksionin main.c i cili është deklaruar në skedarin support.c, atëherë duhet ta deklaroni atë në main gjithashtu duke përdorur klasën e ruajtjes së jashtme.
Mendova të ndaj një situatë ku ekipi im vendosi të përfshijë skedarët .c. Arkitekti ynë përbëhet kryesisht nga module që janë të shkëputura nëpërmjet një sistemi mesazhesh. Këta mbajtës mesazhesh janë publikë dhe thërrasin shumë funksione statike lokale të punonjësve për të kryer punën e tyre. Problemi lindi kur u përpoqëm të merrnim mbulim për rastet tona të vetme të testimit, pasi e vetmja mënyrë për të zbatuar këtë kod privat të zbatimit ishte indirekt përmes ndërfaqes së mesazheve publike. Me disa veçori të punëtorëve në prehrin e pirgut, kjo doli të ishte një makth për të siguruar mbulimin e duhur.
Përfshirja e skedarëve .c na dha mundësinë që të arrijmë tek cog në makinë, ne ishim të interesuar të testonim.
Gjuha C nuk e ndalon një lloj të tillë #include, por njësia e përkthimit që rezulton duhet të jetë ende një C e vlefshme.
Nuk e di se çfarë programi po përdorni me skedarin .prj. Nëse jeni duke përdorur diçka si "make" ose Visual Studio ose çfarëdo tjetër, thjesht sigurohuni që ta vendosni në një listë skedarësh që duhet të përpilohen pa një që nuk mund të përpilohet në mënyrë të pavarur.
Nëse përdoret si duhet, kjo mund të jetë një teknikë e dobishme.
Supozoni se keni një nënsistem kritik të misionit kompleks me një ndërfaqe publike mjaft të vogël dhe shumë kode zbatimi të pazbatuar. Kodi funksionon deri në disa mijëra rreshta, qindra funksione private dhe mjaft të dhëna private. Nëse jeni duke punuar me sisteme të ngulitura jo të parëndësishme, me siguri përballeni me këtë situatë mjaft shpesh.
Zgjidhja juaj ka të ngjarë të jetë e shtresuar, modulare dhe e shkëputur, dhe këto aspekte mund të përfaqësohen dhe përmirësohen me lehtësi duke koduar pjesë të ndryshme të nënsistemit në skedarë të ndryshëm.
Me C, ju mund të humbni shumë duke bërë këtë. Pothuajse të gjitha mjetet ofrojnë optimizime të mira për një njësi të vetme përpilimi, por janë shumë pesimistë për çdo gjë të deklaruar të jashtme.
Nëse vendosni gjithçka në një modul të burimit C, ju merrni -
Përmirësime të performancës dhe madhësisë së kodit - në shumë raste thirrjet e funksionit do të jenë të lidhura. Edhe pa inlining, përpiluesi ka hapësirë për të gjeneruar kod më efikas.
Të dhënat dhe funksionet e nivelit të kanalit janë të fshehura.
Shmangia e ndotjes së hapësirës së emrave dhe përfundimi i saj është se ju mund të përdorni emra më pak të rëndë.
Kompilim dhe lidhje më të shpejtë.
Por ju gjithashtu merrni një rrëmujë të pahijshme kur bëhet fjalë për redaktimin e atij skedari dhe humbni modularitetin e synuar. Kjo mund të tejkalohet duke ndarë kodin burimor në skedarë të shumtë dhe duke i përfshirë ato në një njësi të vetme përpilimi.
Megjithatë, ju duhet të impononi disa konventa për ta trajtuar këtë. Në një farë mase kjo do të varet nga zinxhiri juaj i veglave, por disa tregues të përgjithshëm janë
Vendosni ndërfaqen publike në një skedar të veçantë kokë - duhet ta bëni gjithsesi.
Keni një skedar kryesor .c që përfshin të gjithë skedarët .c të fëmijës. Mund të përfshijë gjithashtu kodin për ndërfaqen publike.
Përdorni mbrojtëse përpiluesi për të parandaluar përfshirjen e kokave private dhe moduleve burimore nga modulet e jashtme të përpilimit.
Të gjitha të dhënat dhe funksionet private duhet të deklarohen statike.
Mbani një dallim konceptual midis skedarëve .c dhe .h. Ai përdor konventat ekzistuese. Dallimi është se do të keni shumë reklama statike në titujt tuaj.
Nëse zinxhiri juaj i veglave nuk ka kuptim, nuk duhet të specifikoni skedarë privatë të zbatimit si .c dhe .h. Nëse përdorni rojet e përfshira, ato nuk do të gjenerojnë kod dhe nuk do të prezantojnë asnjë emër të ri (mund të përfundoni me disa segmente boshe si rezultat). Avantazhi i madh është se mjetet e tjera (p.sh. IDE) do t'i përpunojnë këto skedarë në përputhje me rrethanat.
Kjo është mirë? po do të përpilohet
rekomandohet? Skedarët jo - .c përpilohen në skedarë .obj që janë të lidhur pas kompilimit (nga lidhësi) në një ekzekutues (ose bibliotekë), kështu që nuk ka nevojë të përfshihet një skedar .c në një tjetër. Në vend të kësaj, ka shumë të ngjarë të dëshironi të krijoni një skedar .h që liston funksionet/ndryshoret e disponueshme në një skedar tjetër .c dhe të përfshijë skedarin .h
