Fișiere sursă
Textul unui program C poate fi împărțit în mai multe fișiere sursă. Un fișier sursă este un fișier text care conține fie întregul program, fie o parte din acesta. Când compilați un program sursă, fiecare dintre fișierele sursă constitutive ale acestuia trebuie să fie compilat separat și apoi legat de celelalte fișiere printr-un linker. Fișierele sursă separate pot fi combinate într-un singur fișier sursă, compilat ca întreg, folosind directiva preprocesor #include.
Fișierul sursă poate conține orice combinație completă de directive, instrucțiuni ale compilatorului, declarații și definiții. Integritatea înseamnă că obiectele precum definițiile de funcții, structurile de date sau un set de directive de compilare condiționată conexe trebuie să fie localizate în întregime într-un fișier, adică nu pot începe într-un fișier, ci continuă în altul.
Fișierul sursă nu trebuie să conțină instrucțiuni executabile. Uneori este convenabil să plasați definiții de variabile într-un fișier și să utilizați aceste variabile în alte fișiere declarându-le. În acest caz, definițiile variabilelor devin ușor de căutat și modificate. Din același motiv, constantele și macrocomenzile numite sunt de obicei colectate în fișiere separate și incluse printr-o directivă de preprocesor #include la fișierele sursă care le necesită.
Instrucțiunile compilatorului se aplică, de obicei, numai la anumite secțiuni ale fișierului sursă. Acțiunile specifice ale compilatorului, specificate de directive, sunt determinate de implementarea specifică a compilatorului C.
În exemplul următor, programul sursă este format din două fișiere sursă. Funcții principalși max prezentate în dosare separate. Funcţie principal folosește funcția maxîn procesul de executare a acestuia.
/ * fișierul sursă 1 - funcție principală * /
extern int max (int, int); / * declarația funcției * /
main () / * definiția funcției * /
int w = UNUL, x = DOI, y = TREI;
/ * fișierul sursă 2 - funcție max * /
int max (a, b) / * definiția funcției * /
În primul fișier sursă, funcția max declarat dar nedefinit. Această declarație de funcție se numește provizorie; permite compilatorului să controleze apelul la funcție înainte ca aceasta să fie definită. Definirea functiei principal conţine apeluri de funcţii max.
Liniile care încep cu # sunt directive de preprocesor. Directivele îi spun preprocesorului să înlocuiască identificatorii UNU, DOI, TREI din primul fișier sursă cu valorile corespunzătoare. Directivele nu sunt incluse în cel de-al doilea fișier sursă.
suport.microsoft
Când modificați fișierele originale în Visual C ++ și le salvați, liniile trebuie să fie terminate cu combinația „CR / LF” [retur car, avans linie]. Pe sistemele UNIX, liniile se termină cu „LF”. Prin urmare, când vizualizați fișiere care s-au modificat în grupul Windows pe sisteme UNIX, este posibil să vedeți multe caractere „^ M” în șiruri. Acest lucru se întâmplă doar atunci când editorul nu știe cum să interpreteze fișierul Windows. Visual C ++ poate deschide fișiere în apropierea liniilor care se termină cu crearea UNIX LF. Dacă modificați acest fișier și îl salvați din Visual C ++, atunci acesta este salvat în format Windows (veți vedea CR / LF și nu LF care era anterior pe sistem).
Acest articol descrie procedurile pentru salvarea unui fișier modificat creat pe o platformă Windows într-un format care poate fi utilizat pe sisteme UNIX.
NOTĂ: Visual C ++.NET IDE conține funcții disponibile pentru salvarea unui fișier în format UNIX. În IDE, salvați fișierul cu Salvează ca..., selectați Salvare din lista verticală Salvați cu codificare..., și apăsați thrn da... Selectați Codificarea șirurilor din lista verticală UNIX (LF)și apoi faceți clic O.K.
Puteți folosi următorii pași pentru a crea un proiect de aplicație consolă Win32 care convertește un fișier care conține „CR / LF” la terminarea de linie pentru „LF”:
- Pentru a crea un nou proiect gol, numit DOS2UNIX, folosind aplicațiile de consolă Win32.
- Din Fişier meniu, apăsați butonul Nouși apoi faceți clic Fișiere Tab.
- Te rog selecteaza C / C ++ Fișier sursăși introduceți numele noului fișier DOS2UNIX.cpp.
- Lipiți următorul cod în DOS2UNIX.cpp:
#include
#include #include folosind namespace std; int main (int argc, char * argv) (dacă (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; } - Din Clădire meniu, apăsați butonul Se creează DOS2UNIX.exe pentru a crea un fișier EXE.
Poate fi necesar să verificați acest fișier exe pentru a vedea dacă funcționează corect. Pentru a face acest lucru, deschideți fișierul în editorul binar Visual C ++ Când alegeți Deschis in grup Fişier meniu selectând DOS2UNIX.ex, Setare Deschide ca La care Binarși apoi făcând clic Deschis... De exemplu, dacă fișierul conține „hellocrlfworld”, fișierul de date binare (hexazecimal) ar arăta astfel:
48 65 6 C 6 C 6F 0 D 0A 57 6F 72 6 C 64
Aceasta este echivalentă cu:
Hei
Pace
La promptul de comandă, rulați dos2unix.exe
Acesta poate fi folosit împreună cu Modelul de automatizare Visual C ++ pentru a automatiza întregul proces. Macro-urile de script Microsoft Visual Basic simple pot fi scrise pentru a apela acest instrument, dar mai întâi trebuie să adăugați acest instrument Serviciu meniul arata asa:
- Din Serviciu meniu, apăsați butonul Personalizareși apoi faceți clic Serviciu Tab.
- Specificați un nume, cum ar fi DOS2UNIX și specificați calea completă către fișierul Dos2unix.exe în Echipă câmp de editare.
- Setați argumentul la $ (Filename) $ (FileExt).
- Specificați directorul sursă $ (WkspDir) (furnizați propria cale).
Pentru a testa programul, deschideți fișierul într-un editor Visual C ++ și apoi din Serviciu meniul de lansare DOS2UNIX mijloace. Veți vedea că fișierul deschis în editor are toate caracterele CR eliminate.
Dacă doriți să automatizați acest proces, gestionați astfel încât de fiecare dată când salvați un fișier deschis în editorul Visual C ++, instrumentul DOS2UNIX.exe este apelat pentru a elimina 0x0d s, apoi utilizați următoarea macrocomandă VBScript:
"Acest eveniment este declanșat de fiecare dată când documentul este salvat în Editorul VC ++. Sub Application_DocumentSave (theDocument)" Aceasta va apela instrumentul utilizatorului din meniul Instrumente. „Schimbați numărul în funcție de ceea ce aveți. În mod implicit doar dvs.” aveți 6 instrumente în meniul Instrumente, astfel încât instrumentul DOS2UNIX va fi al 7-lea. ExecuteCommand „UserTool7” End Sub
Acest cod VBScript va funcționa numai dacă aveți fișierele deschise în Editorul Visual C ++. Acesta este singurul mod de a apela un fișier exe dintr-o macrocomandă VBScript (o macrocomandă VBScript nu poate fi transmisă parametrilor). Puteți scrie în schimb și va fi mai flexibil. Apelați instrumentul „DOS2UNIX.exe” din programul de completare fără a fi nevoie să îl adăugați Serviciu meniul.
În Visual C ++ folosind macrocomanda VBScript furnizată:
- Deschideți un fișier existent cu extensia .dsm sau creați unul.
- Lipiți codul furnizat anterior în fișier.
- În Visual C ++, urmați acești pași.
- Din Serviciu meniu, apăsați butonul Personalizare.
- Faceți clic pe butonul Macro și fișiere suplimentare Tab.
- Faceți clic pe butonul Prezentare generală descărcați fișierul .dsm care conține macrocomanda. Odată ajuns, fișierul .dsm a fost selectat în Prezentare generală caseta de dialog, fișierul va apărea în Suplimente și macrocomenzi o listă de fișiere folosind caseta de selectare selectată de lângă aceasta.
- Faceți clic pe butonul Închide a continua.
Acum, dacă deschideți fișierul în editorul Visual C ++ și salvați din fișier Fişier meniul apelat de macrocomandă și toate 0x0d s vor fi eliminate din fișierul deschis. Deoarece acest lucru va afecta orice fișier pe care îl păstrați de acum înainte și se va aplica oricărui proiect pe care îl deschideți în viitor, asigurați-vă că dezactivați macrocomanda din Serviciu meniu folosind Personalizare(debifați caseta de lângă macrocomandă).
În funcție de mediul dvs. de construcție (nu veți specifica), s-ar putea să descoperiți că funcționează exact așa cum doriți.
Cu toate acestea, există multe medii (atât IDE-uri, cât și multe Makefile-uri realizate manual) care așteaptă să compileze * .c - dacă se întâmplă acest lucru, este posibil să întâlniți erori de linker din cauza simbolurilor duplicate.
Ca regulă generală, această practică trebuie evitată.
Dacă trebuie să # includeți sursa (și în general ar trebui evitată), utilizați un fișier diferit pentru fișier.
Includerea fișierului C într-un alt fișier este legală, dar nu este recomandabilă decât dacă știți exact de ce o faceți și ce încercați să realizați.
Sunt destul de sigur că, dacă postați aici un motiv pentru care întrebarea dvs. este comunicată comunității, veți găsi o altă modalitate potrivită de a vă atinge obiectivul (notați „aproape”, deoarece ar putea fi o soluție dat fiind contextul).
Apropo, am ratat partea a doua a întrebării. Dacă fișierul C este inclus într-un alt fișier și în același timp inclus în proiect, este posibil să vă confruntați cu problema simbolurilor duplicate, de ce legarea obiectelor, adică aceeași funcție va fi definită de două ori (cu excepția cazului în care sunt statice ).
Limbajul C nu interzice acest tip de #include, dar unitatea de traducere rezultată trebuie să fie în continuare C validă.
Nu știu ce program utilizați cu fișierul .prj. Dacă utilizați ceva de genul „make” sau Visual Studio sau orice altceva, asigurați-vă că ați setat lista de fișiere pentru a fi compilate fără unul care nu poate fi compilat independent.
Puteți folosi compilatorul gcc pe Linux pentru a lega două fișiere cu o singură ieșire. Să presupunem că aveți două fișiere c, unul este „main.c” și celălalt este „support.c”. Deci comanda pentru a conecta aceste două
Gcc main.c support.c -o main.out
Aceste două fișiere vor fi legate la aceeași ieșire main.out. Pentru a rula ieșirea, comanda ar fi
./principal.out
Dacă utilizați funcția main.c care este declarată în fișierul support.c, atunci trebuie să o declarați practic folosind și clasa de stocare externă.
Folosită corect, aceasta poate fi o tehnică utilă.
Să presupunem că aveți un subsistem complex de misiune critică, cu o interfață publică destul de mică și mult cod de implementare neimplementat. Codul rulează până la câteva mii de linii, sute de funcții private și destul de multe date private. Dacă lucrați cu sisteme încorporate non-triviale, probabil că vă confruntați destul de des cu această situație.
Soluția dvs. este probabil să fie stratificată, modulară și decuplată, iar aceste aspecte pot fi reprezentate și îmbunătățite convenabil prin codificarea diferitelor părți ale subsistemului în fișiere diferite.
Cu C, poți pierde mult făcând asta. Aproape toate instrumentele oferă optimizări decente pentru o singură unitate de compilare, dar sunt foarte pesimiste cu privire la orice declarație externă.
Dacă puneți totul într-un singur modul C original, obțineți -
Îmbunătățiri de performanță și dimensiunea codului - În multe cazuri, apelurile de funcții vor fi inline. Chiar și fără inlay, compilatorul are capacitatea de a genera cod mai eficient.
Datele și funcțiile la nivel de canal sunt ascunse.
Evitarea poluării spațiului de nume și a consecințelor acesteia - puteți folosi nume mai puțin greoaie.
Compilare și conectare mai rapide.
Dar ai și o mizerie răutăcioasă când vine vorba de editarea fișierului respectiv și pierzi modularitatea implicită. Acest lucru poate fi depășit prin împărțirea codului sursă în mai multe fișiere și includerea lor într-o singură unitate de compilare.
Cu toate acestea, trebuie să aplicați unele convenții pentru a gestiona acest lucru. Va depinde într-o oarecare măsură de lanțul dvs. de instrumente, dar unele indicații generale sunt:
Puneți interfața publică într-un fișier antet separat - tot ar trebui să faceți asta.
Aveți un fișier principal .c care include toate fișierele .c secundare. De asemenea, poate include cod pentru o interfață deschisă.
Utilizați gardieni pentru compilator, astfel încât anteturile private și unitățile sursă să nu fie incluse de unitățile de compilare externe.
Toate datele și funcțiile personale trebuie declarate statice.
Mențineți o distincție conceptuală între fișierele .c și .h. Folosește convențiile existente. Diferența este că veți avea o mulțime de anunțuri statice în titluri.
Cu excepția cazului în care lanțul dvs. de instrumente impune vreun motiv, nu trebuie să specificați fișierele de implementare private ca .c și .h. Dacă utilizați gărzile incluse, acestea nu vor genera cod și nu vor introduce nume noi (ca urmare, este posibil să întâlniți câteva segmente goale). Avantajul uriaș este că alte instrumente (cum ar fi IDE) vor gestiona aceste fișiere în mod corespunzător.
Extensia de fișier este irelevantă pentru majoritatea compilatoarelor C, așa că va funcționa.
Cu toate acestea, în funcție de fișierul sau setările proiectului, fișierul c inclus poate genera un fișier obiect separat. Când este conectat, acest lucru poate duce la caractere dublu definite.
ar trebui să adaugi un titlu ca acesta
#include
notă: ambele fișiere trebuie să fie în aceeași locație
Puteți include corect fișierele .C sau .CPP în alte fișiere sursă. În funcție de IDE-ul dvs., puteți preveni, de obicei, dubla legare, uitându-vă la proprietățile fișierelor sursă pe care doriți să le includeți, de obicei făcând clic dreapta pe ele și făcând clic pe proprietăți și debifând / bifați compilare / link / exclude din asamblare sau orice alt varianta... poate. Sau nu puteți include fișierul în proiectul în sine, așa că IDE-ul nici nu știe că există și nu va încerca să-l compileze. Și cu makefiles, pur și simplu nu ai pus fișierul în el pentru compilare și legare.
EDIT: Îmi pare rău, am dat răspunsul în loc de celelalte răspunsuri :(
O întrebare similară mi-a fost pusă recent de un coleg care începe să programeze în limbajul C. Și m-am gândit că acesta este un motiv bun pentru a împărtăși înțelegerea mea despre această problemă. Pentru că nici programatorii cu experiență nu au întotdeauna aceleași puncte de vedere în această chestiune.
Aceasta este parțial o chestiune de gust, așa că oricine este interesat de cum o fac, bine ați venit la cat.
În ciuda faptului că „întregul adevăr” despre fișierele h este conținut în secțiunea corespunzătoare a descrierii preprocesorului gcc, îmi voi permite câteva explicații și ilustrații.
Deci, literalmente, un fișier antet (h-file) este un fișier care conține declarații C și definiții macro destinate utilizării în mai multe fișiere sursă (c-fișiere). Să ilustrăm asta.
Este ușor de observat că funcțiile 1 și 2, precum și macro-ul 2, sunt menționate în ambele fișiere. Și deoarece includerea fișierelor antet produce aceleași rezultate ca și copierea conținutului în fiecare fișier C, putem face următoarele: 
Astfel, pur și simplu am selectat partea comună din cele două fișiere și am plasat-o în fișierul antet.
Dar este fișierul antet o interfață în acest caz?
- Dacă trebuie să folosim funcționalitatea pe care funcțiile 1 și 2 le implementează în altă parte, atunci Da
- Dacă macro-ul 2 este destinat numai utilizării în fișierele Unit1.c și Unit2.c, atunci nu are loc în fișierul de interfață
Răspunsul la această întrebare depinde de detaliile de implementare ale funcțiilor de interfață și de locul în care sunt implementate. De exemplu, dacă faceți diagramele mai detaliate, vă puteți imagina o variantă când funcțiile de interfață sunt implementate în fișiere diferite:
Această implementare duce la o coeziune ridicată a codului, testabilitate scăzută și dificultăți în reutilizarea unor astfel de module.
Pentru a nu avea astfel de dificultăți, consider întotdeauna fișierul C și fișierul antet ca un singur modul. In care,
- fișierul antet conține doar acele declarații de funcții, tipuri, macro-uri care fac parte din interfața acestui modul.
- Fișierul C, la rândul său, trebuie să conțină implementarea tuturor funcțiilor declarate în fișierul h, precum și tipurile private, macrocomenzile și funcțiile care sunt necesare pentru implementarea interfeței.
Diagrama arată că de fapt avem de-a face cu două module independente, fiecare dintre ele având propria sa interfață sub forma unui fișier antet. Acest lucru face posibilă utilizarea doar a interfeței care este cu adevărat necesară în acest caz particular. În plus, aceste module pot fi testate independent unele de altele.
Este posibil ca cititorul să fi observat că macrocomanda 2 din fișierul antet a revenit din nou ca o copie în ambele fișiere C. Desigur, acest lucru nu este foarte convenabil de întreținut. Dar nici a face această macro parte a interfeței nu este corectă.
În astfel de cazuri, prefer să fac un fișier antet separat care să conțină tipurile și macrocomenzile necesare pentru mai multe fișiere C.
Sper că am reușit să identific acele entități care trebuie plasate în fișierele de antet. Și, de asemenea, pentru a arăta diferența dintre interfețele și fișierele care conțin declarații și macrocomenzi solicitate de mai multe fișiere C.
Vă mulțumim pentru atenția acordată materialului.
votează online (8)
Includerea fișierului C într-un alt fișier este legală, dar nu este recomandabilă decât dacă știți exact de ce o faceți și ce încercați să realizați.
Sunt destul de sigur că, dacă postați aici un motiv pentru care întrebarea dvs. este comunicată comunității, veți găsi o altă modalitate potrivită de a vă atinge obiectivul (notați „aproape”, deoarece ar putea fi o soluție dat fiind contextul).
Apropo, am ratat partea a doua a întrebării. Dacă fișierul C este inclus într-un alt fișier și în același timp inclus în proiect, este posibil să vă confruntați cu problema simbolurilor duplicate, de ce legarea obiectelor, adică aceeași funcție va fi definită de două ori (cu excepția cazului în care sunt statice ).
Extensia de fișier este irelevantă pentru majoritatea compilatoarelor C, așa că va funcționa.
Cu toate acestea, în funcție de fișierul sau setările proiectului, fișierul c inclus poate genera un fișier obiect separat. Când este conectat, acest lucru poate duce la caractere dublu definite.
În funcție de mediul dvs. de construcție (nu veți specifica), s-ar putea să descoperiți că funcționează exact așa cum doriți.
Cu toate acestea, există multe medii (atât IDE-uri, cât și multe Makefile-uri realizate manual) care așteaptă să compileze * .c - dacă se întâmplă acest lucru, este posibil să întâlniți erori de linker din cauza simbolurilor duplicate.
Ca regulă generală, această practică trebuie evitată.
Dacă trebuie să # includeți sursa (și în general ar trebui evitată), utilizați un fișier diferit pentru fișier.
Puteți folosi compilatorul gcc pe Linux pentru a lega două fișiere cu o singură ieșire. Să presupunem că aveți două fișiere c, unul este „main.c” și celălalt este „support.c”. Deci comanda pentru a conecta aceste două
Gcc main.c support.c -o main.out
Aceste două fișiere vor fi legate la aceeași ieșire main.out. Pentru a rula ieșirea, comanda ar fi
./principal.out
Dacă utilizați funcția main.c care este declarată în fișierul support.c, atunci trebuie să o declarați practic folosind și clasa de stocare externă.
M-am gândit să împărtășesc o situație în care echipa mea a decis să includă fișierele .c. Arhitectul nostru este compus în principal din module care sunt decuplate printr-un sistem de mesagerie. Acești handlere de mesaje sunt publice și apelează la multe funcții locale de lucru statice pentru a-și face treaba. Problema a apărut când am încercat să obținem acoperire pentru cazurile noastre de testare unice, deoarece singura modalitate de a implementa acest cod privat de implementare a fost indirect prin interfața comună de mesagerie. Cu unii dintre genunchii lucrătorului în stivă, acest lucru s-a dovedit a fi un coșmar pentru a asigura o acoperire adecvată.
Includerea fișierelor .c ne-a oferit posibilitatea de a ajunge la roata din mașină, eram interesați de testare.
Limbajul C nu interzice acest tip de #include, dar unitatea de traducere rezultată trebuie să fie în continuare C validă.
Nu știu ce program utilizați cu fișierul .prj. Dacă utilizați ceva de genul „make” sau Visual Studio sau orice altceva, asigurați-vă că ați setat lista de fișiere pentru a fi compilate fără unul care nu poate fi compilat independent.
Folosită corect, aceasta poate fi o tehnică utilă.
Să presupunem că aveți un subsistem complex de misiune critică, cu o interfață publică destul de mică și mult cod de implementare neimplementat. Codul rulează până la câteva mii de linii, sute de funcții private și destul de multe date private. Dacă lucrați cu sisteme încorporate non-triviale, probabil că vă confruntați destul de des cu această situație.
Soluția dvs. este probabil să fie stratificată, modulară și decuplată, iar aceste aspecte pot fi reprezentate și îmbunătățite convenabil prin codificarea diferitelor părți ale subsistemului în fișiere diferite.
Cu C, poți pierde mult făcând asta. Aproape toate instrumentele oferă optimizări decente pentru o singură unitate de compilare, dar sunt foarte pesimiste cu privire la orice declarație externă.
Dacă puneți totul într-un singur modul C original, obțineți -
Îmbunătățiri de performanță și dimensiunea codului - În multe cazuri, apelurile de funcții vor fi inline. Chiar și fără inlay, compilatorul are capacitatea de a genera cod mai eficient.
Datele și funcțiile la nivel de canal sunt ascunse.
Evitarea poluării spațiului de nume și a consecințelor acesteia - puteți folosi nume mai puțin greoaie.
Compilare și conectare mai rapide.
Dar ai și o mizerie răutăcioasă când vine vorba de editarea fișierului respectiv și pierzi modularitatea implicită. Acest lucru poate fi depășit prin împărțirea codului sursă în mai multe fișiere și includerea lor într-o singură unitate de compilare.
Cu toate acestea, trebuie să aplicați unele convenții pentru a gestiona acest lucru. Va depinde într-o oarecare măsură de lanțul dvs. de instrumente, dar unele indicații generale sunt:
Puneți interfața publică într-un fișier antet separat - tot ar trebui să faceți asta.
Aveți un fișier principal .c care include toate fișierele .c secundare. De asemenea, poate include cod pentru o interfață deschisă.
Utilizați gardieni pentru compilator, astfel încât anteturile private și unitățile sursă să nu fie incluse de unitățile de compilare externe.
Toate datele și funcțiile personale trebuie declarate statice.
Mențineți o distincție conceptuală între fișierele .c și .h. Folosește convențiile existente. Diferența este că veți avea o mulțime de anunțuri statice în titluri.
Cu excepția cazului în care lanțul dvs. de instrumente impune vreun motiv, nu trebuie să specificați fișierele de implementare private ca .c și .h. Dacă utilizați gărzile incluse, acestea nu vor genera cod și nu vor introduce nume noi (ca urmare, este posibil să întâlniți câteva segmente goale). Avantajul uriaș este că alte instrumente (cum ar fi IDE) vor gestiona aceste fișiere în mod corespunzător.
Este în regulă? da se va compila
este recomandat? nu - fișierele .c sunt compilate în fișiere .obj care sunt legate după compilare (de către linker) într-un executabil (sau bibliotecă), deci nu este nevoie să includeți un fișier .c într-un altul. În schimb, cel mai probabil ați dori să faceți un fișier .h care să enumere funcțiile/variabilele disponibile într-un alt fișier .c și să includă un fișier .h
