Unde pot obține o literatură bună despre C ++?
Gustul și culoarea prietenilor nu este.
Cu toate acestea, cărțile cu adevărat bune pentru începători nu sunt prea multe în masa generală de gunoi.
Personal mi-a plăcut:
Nu cunosc încă literatura relevantă.
Crearea unui proiect, conectarea codului :: blocuri Irrlicht
?page_id = 497
Înapoi la început
Ce este SVN / Subversion și cum îl folosesc? Unde pot găsi hosting gratuit pentru SVN?
Înapoi la început
Ce arata proiectul C ++ minim sigur (consola)
I. Ar trebui să fie scris folosind excepții și SEH (win32) "origine" și CRTL (C + +). sau utilizând funcțiile de comutare a excluderilor CRTL în modul de suport al SEH.
II. Și, de asemenea, cu aplicarea unui set de macro-uri prea puțin cunoscute de preprocesor C ++, cum ar fi
__LINE__ este linia curentă de cod,
__FILE__ - calea sistemului către fișierul / modulul curent,
__FUNCTION__ este numele f-tiunii din corpul caruia se afla macro-ul preprocesorului.
III. Mai mult decât atât, eu personal cred că este necesar să înceapă începători C ++ cu acest lucru (simple depanare: excepții (ambele soiuri) + 3 aceste macrocomenzi).
(toate exemplele au fost compilate sub win32 minGW + codblocks)
Cod exemplu pentru "eroare universală" C ++:
Exemplu UEF (Funcția de excepție nefolosită). API-ul F-tion win vă permite să gestionați excepțiile SEH:
Schema finală pregătită pentru codificare cu cea mai simplificată "eroare de captare".
Insistența publică notifică faptul că toate instrumentele prezentate aici sunt utilizate pentru a urmări și să corecteze erorile, să nu depășească erorile atunci când acestea sunt stocate și nu pentru a realiza programul de sănătate umplute cu erori.
Sfătuiți să manifeste prudență, folosind Seh-capcane în timpul release (Release) setările de compilare / compilare (sunt sfătuiți să dezactivați Instrumentul de optimizare pentru viteză, sau să-l pună în mod implicit, pentru a SEH a continuat să fie prins în eliberarea „perioadă“. Dar este, probabil, pentru VC ++, cum funcționează în codeblocks încă nu este clar.
Una dintre opțiunile pentru un proiect C ++ minimal sigur:
minimal.zip În plus față de main.cpp, proiectul conține min_dbg.h și win_dbg.h (4.79 KB) 185 descărcări
+
Aș fi recunoscător dacă cineva de la moderatori va adăuga informații relevante despre Linkus / Unix.
Înapoi la început
2. Calculul identificatorului de clasă locală:
Pentru ca __COUNTER__ să funcționeze corect atunci când se împarte * .h / *. Cpp în blocul de coduri ::, pot fi necesare mai multe acțiuni suplimentare.
1. Trebuie să lăsați doar 1 obiectiv de construcție:
PCM pe proiect -> proprietăți. -> fila Construiți țintă.
Și eliminați daws-urile din toate fișierele * .cpp, cu excepția main.cpp (pe acest principiu daws puteți (chiar trebuie să-l plece).
2. Și este posibil să aveți nevoie (sau nu poate să aveți nevoie) de PCM pe toate fișierele * .cpp din proiect-> proprietăți-> tab-build-> debifați caseta de validare "File link".
(esența acestor acțiuni este că totul trebuie mai întâi să fie colectat într-un fișier text și apoi să se vadă deja în fișierul obiect, altfel __COUNTER__ nu va funcționa corect).
3. Este de la sine înțeles că casetele de selectare "Link file" și "Compile File" ar trebui șterse în toate fișierele de proiect .h.
Dar acest lucru ar trebui să fie deja implicit și ar trebui să fie doar pentru compilarea normală.
4. Metoda de depășire a constrângerilor __COUNTER__
În hacker-ul din industrie și în câteva versiuni "de stejar" ale automatizării de calcul al ID-urilor (care nu sunt compatibile nici cu specializarea parțială a șabloanelor, nici chiar cu clasele, pur globale etc.)
3. Calculul ID-ului bibliotecii, vezi 2 referințe la începutul articolului.
În combinație, proiectul este aproape de proiectul minim de câștig API. Și este potrivit pentru construirea OGL, DirectX și a unor proiecte similare pe bază proprie.
4. Identificarea în Irrelikht.
Mai multe detalii despre operațiile de biți.
Irrliht folosește pentru formarea ID makrosnuyu MAKE_IRR_ID psevdof-TION ( 'm', 'y' i, 'd') șir de 4 octeți "direct" convertibile într-un ID numeric tip de 4 octeți.
exemplu:
Înapoi la început
Cum să setați un punct de intrare. în VC ++ și în bloc-uri de cod minGW +.
slabnessforcats a scris: Verificați opțiunile de linker. Există de obicei o opțiune în care puteți specifica funcția de punct de intrare. main () este doar implicit.
Dacă utilizați Visual Studio.NET selectați proiectul Proprietăți-> Configurare Proprietăți-> linker> Advanced și pe panoul din dreapta al dialogului este un loc pentru numele funcției punct de intrare.
Verificați setările linkerului. De obicei, există o opțiune în care puteți specifica funcția punctului de intrare. Principalul () este pur și simplu implicit.
Dacă utilizați Visual Studio .NET, selectați
proprietățile proiectului-> Proprietăți de configurare-> Linker-> Avansat
iar în panoul din dreapta al ferestrei există un loc pentru numele funcției punctului de intrare.
(pentru VC ++ / VS nu a verificat) [/ spoiler]
minGW + bloc de coduri (gcc)
[Spoilere]
JosAH a scris: Pentru gcc încercați "-e
în loc de punctul de intrare implicit "principal".
cu plăcere,
Jos
Pentru gcc, încercați să utilizați pavilionul "-e linker"
în loc de punctul de intrare "primar" implicit.
Sincer, Jos
Greg Chicares a scris: În situații ca dvs., ar fi mai ușor și mai robust
au un nume simplu. De aceea, C ++ oferă "extern" C "". dacă
scrieți
extern "C" void f ();
atunci numele f () nu va fi "mangled" - va fi același nume
pe care compilatorul le-ar folosi pentru această funcție:
void f (void);
într-un program C.
Acest nume este '_f', prefixat cu '_' deoarece este normal
convenție pentru legătura C, pentru toți compilatorii de pe această platformă.
Și trebuie să adăugați prefixul "_" la numele "_f" deoarece aceasta este convenția limbajului C pentru linkuri, una pentru toți compilatorii de pe această platformă.
P.S. tot ce trebuie să vă amintiți este că atunci când vă stabiliți propriul punct de intrare în program, veți prelua implementarea returnării "corecte" în sistem.
Care nu este întotdeauna ușor, adesea periculos și consumatoare de timp. Codul nu este dat ca un ghid al acțiunii (este mult mai avantajos să rămânem cu punctele principale și de intrare în mod implicit "), dar pentru a înțelege mai bine mecanica C ++.
Vom avea nevoie de acest lucru pentru a implementa punctul de intrare în Dll. Și pentru a înțelege prichny pe care "exemplul implicit" pentru DLL din codeblocks "pentru un motiv oarecare" nu funcționează. [/ Spoiler]
Înapoi la început
Cum se lucrează cu dll? (Creare / conectare): în VC ++ și în minGW + codblocks.
Această carte se ocupă de mecanismul dll, care lucrează cu acesta. Da, și în informațiile despre VC ++ foarte mult.
Iată cum să lucrați cu dll în minGW + codeblocks - această informație nu este prea mare și este foarte slabă.
Pentru că voi împărtăși experiența mea. Experiența "unui laic este forțat să se ocupe de acest lucru".
Thriller "Dificultăți cu care și întâlnit a creat un proiect DLL sub minGW":
[spoiler] I. Crearea unui proiect DLL.
Crearea unui proiect din bibliotecă dinamică în Cod: blocuri + minGW:
File-> new-> project-> Dynamic Link Library
și apoi prin procedura standard.
Există 2 fișiere "main.cpp" și "main.h"
Punctul de intrare al proiectului creat automat, funcția DllMain arată astfel:
Cel mai probabil totul este compilat în detaliu. Există 2 fișiere * .dll și * .a. Fișierul * .a trebuie să fie specificat în opțiunile de linker în mod obișnuit:
PCM pe proiect -> Opțiuni de construire. -> fila Setări linker
iar în bibliotecile Link adăugați calea către "biblioteca dorită".
A * .dll poate fi plasat lângă aplicația aplicației. Sau redirecționați căile fișierului dll generat în opțiunile de compilatoare de acolo:
PCM pe proiect -> Proprietăți. -> Cărți de direcționare a obiectivelor -> Câmp ieșire nume fișier
Introduceți aici calea către fișierul * .exe al programului principal.
Vorkspace care combină ambele proiecte într-unul din blocurile de coduri poate fi creat făcând clic pe acesta cu PCM și selectând "salvați ca" (vorkspace este situat deasupra proiectului superior deschis). Puteți conecta proiectul 2 la spațiul de lucru prin simpla deschidere a blocurilor de coduri create de proiectul anterior.
Toate celelalte funcții, trebuie să declare "exportul dll" ca extern "C" și __declspec (dllexport). Acest lucru este văzut în mod clar din codul generat de "implicit":
Având în vedere informațiile de la ultima postare, semnificația acestei intrări ar trebui să devină mai clară pentru dvs. Toate "exportul" f-tsii sunt declarate ca Si-shnye. Cu toate consecințele. (neprietenos pentru clase, variabile de statică și operator nou, deși neprietenența la noi sau chiar malloc merge mai adânc)
În această fază externă "C" se poate găsi cu ușurință C ++ imbricate f-tion destul de prietenos cu cipurile C ++ și acest lucru este normal.
Nu voi lua în considerare în detaliu toate dll-urile de bucătărie (ar trebui să fie deja minime), care este interesat de mai multe detalii referitoare la cartea lui D. Richter.
II. Conectarea DLL-ului la proiect.
Puteți să conectați o bibliotecă dinamică în 2 moduri:
1 sau setând calea la * .lib sau * .a + în setări prin atașarea * .h unui fișier libra prin #include. Ei bine și punerea DLL în proiect. Nu ar trebui să existe probleme aici, mai ales dacă conectați totul la proiect pe baza aceluiași compilator care a creat DLL-ul.
2 sau "direct" (fără * .lib sau * .a) folosind
2. __stdcall este un "acord multi-platform". Polusishnopaskalnoe. În teorie, o bibliotecă constând din p-tiile __stdcall ar trebui să aibă același apetit „mânca“ compilatoare diferite, limbi diferite, și așa mai departe (care este motivul pentru care toate de export delfin Fct sau a declarat ca obyavlyutsya stdcall)
Se adaugă la numele f-tsii tynyku tip: "@ 4", de exemplu:
SomeFunction @ 4
O subliniere (_) este prefixată cu numele. Numele este urmat de semnul at (@) urmat de numărul de octeți (în zecimal) din lista de argumente. Prin urmare, funcția declarată int int () este următoarea: _func @ 12
Sublinierea (_) este un prefix al numelui.
Numele este urmat de un semn (@), urmat de numărul de octeți din lista de argumente (în sistemul zecimal). Astfel, funcția declarată ca int func (int a, dublu b) este formatată după cum urmează: _func @ 12
La aceasta pot adăuga că minGW nu a adăugat sublinieri. De ce? Și aici nu adaugă.
). Pe aceasta, atunci mega-numele (cu câinele și numărul) și le puteți apela, de exemplu:
Dacă specificați o bibliotecă în setările compilatorului, atunci trucurile cu funcțiile funcțiilor de obicei nu contează, conectați doar * .h, specificați fișierul * .a și puneți * .dll la utilizator. [/ Spoiler]
Înapoi la început
Cum se creează secțiuni comune în proiecte DLL? În VC ++ și în minGW?
De ce?
[spoiler] Inițiază o încărcare DLL din unul dintre procese, dar după aceea DLL-ul este "încărcat" în toate procesele din sistem.
În procesul de "conectare" a DLL-ului la un nou proces, întregul model de date "DLL" este creat din nou (DLL este unul, iar modelele de date ale acestui DLL sunt diferite pentru fiecare proces). În același timp, acest model este, de asemenea, izolat de procesul de aplicare cu care se efectuează interacțiunea. Și din alte procese / dll. Ie "implicit" toate datele sunt repornite.
Aceasta înseamnă că, dacă o variabilă dintr-un proces învecinat a fost neinvitată, atunci în procesul actual va fi "curată curată" și va trebui fie reinitializată de fiecare dată când vă alăturați dll procesului. Sau setați toate valorile implicite, fără speranța de a le schimba în procesul descărcărilor dll din procesele / aplicațiile învecinate.
Puteți să ocoliți această restricție dacă creați date într-un segment partajat. Aceasta este o zonă "comună" în memorie (ceva asemănător variabilelor statice ale C ++), în care puteți scrie / citi toate procesele în care se încarcă dll-ul.
În minGW (gcc?).
Conform minWW, găsirea informațiilor a fost cea mai dificilă.
Pentru a pune o variabilă în secțiunea Partajare, trebuie să o declarați cu atributul special __attribute __ ((secțiunea (". Shr"), partajată))
exemplu:
Înapoi la început
Cum se leagă clasele | modulele de fișiere 1. de piesă și 2. toate în 1 * .o?
Notă:
[spoiler] Ordinea de conectare descrisă prin * .h este posibilă cu bibliotecile (atât statice, cât și dinamice). Diferența este că biblioteca ar trebui să fie conectată la opțiunile linker:
PCM pe proiect -> Opțiuni de construire. -> fila Setări linker
Adăugați calea spre biblioteca necesară * .a
Dacă biblioteca dinamică este pusă în fișierul * .dll
Apoi, puteți folosi funcțiile / clasele bibliotecii cu fișierele asociate * .h (desigur, deoarece biblioteca este codul mașinii, așa că "bine" nu există clase în ea, dar există doar f-tions și date, dar puteți accesa entități de clasă prin * .h). [/ spoiler]
cod :: blocuri
[spoiler] fișierele Karochsch cpp au fost compilate pentru h asociat (deși eu însumi nu am fost obișnuit cu asta și trăiesc bine!) în blocuri de cod ::. Dar poți.
Este necesar
1. Adăugați filtrele la proiect. Acest lucru se poate face într-o varietate de moduri.
Metoda 1:
Fișier-> nou -> Fișier. -> selectați * .h sau * .cpp
În procesul de creație, nu uitați să puneți un daw
Adăugați fișierul în proiect activ
În construirea țintei (lor)
Și nu uitați să puneți un daw pe depanare / eliberare.
Metoda 2:
PCM pe proiect în fereastra din stânga -> Adăugare fișiere. -> selectați fișierele existente pentru încorporarea în proiect.
2. Adăugați fișiere în lista de direcții de construire (de obicei se adaugă automat acolo, dar orice poate fi) și puneți-o la dispoziție (și care nu este suficientă pentru toate):
PCM pe proiect -> proprietăți. -> Construiți fila Ținte -> în "Construiți fișiere țintă"
toate fișierele trebuie să fie conectate (adică daws trebuie să fie atașat).
3. PCM pe fișierul din câmpul proiectului din stânga -> proprietăți. -> da daws Fișierul Compile și fișierul Link. (aceasta specifică faptul că fiecare pereche * .h / * .cpp trebuie compilată într-un fișier de obiecte separat)
Și este obligatoriu să pui un daw pe debag și / sau relese. Obligatoriu. În caz contrar, blocul de coduri nu va vedea fișierele.
Acum se pot conecta module (adică fișiere de clasă) cu * .h antete, respectiv * .cpp vor fi mapate automat la ele.
Cu mai multă precizie * .h nu se va potrivi chiar cu * .cpp și corespunzător. * .o - fișiere obiect deja compilate și legate.
Acesta este stilul C ++.
4. Pentru a întoarce totul înapoi (astfel încât toate obiectele sunt înghesuiți într-un fișier 1 .o, de exemplu, în scopuri compacte și că zeci de .o nu rumble în ochi), puteți efectua o operație inversă.
Asta este
PCM pe fișier -> proprietăți. -> eliminați linkul.
Și puteți doar
PCM pe proiect -> proprietăți. -> Construiți fila Ținte -> în fereastra "Construiți fișierele țintă" din partea de jos, eliminați daws-urile din toate fișierele, cu excepția main.cpp
După aceea, va trebui să conectați (mai precis, chiar "legați unul de altul") toate modulele de * .cpp, deoarece nu vor fi potrivite automat * .h. Prin urmare, va trebui să monitorizați îndeaproape legăturile dintre modulele din proiect. Ei bine, da, este mai bine, există mai puține oportunități pentru tot felul de "ambiguități", ambiguități, "comportamente imprevizibile" etc.
În plus, toate elementele / clasele proiectului vor fi scrise într-un singur fișier main.o
Macro-urile preprocesor, cum ar fi __COUNTER__, vor funcționa corect oriunde în cod, în orice modul, arbitrar departe de main.cpp.
Acesta este stilul C.
Ei bine, este deja clar că "stilurile" pot fi combinate. Asta este, faceți niște fișiere * .o și prin * .h. Și unii, fără a împărți cramă într-un singur modul de obiect de proiect. În funcție de planurile de proiectare / arhitectură. [/ Spoiler]
Înapoi la început