Inainte ati putea citi si "Documentation/CodingStyle" aflat in sursa de kernel a Linux-ului. Scuzati-ma daca ma inspir putin. Manualul gcc este si el binevenit.

h2. 0

h2. Pont #0

Prefer C in loc de C++: e mai robust putin ceea ce ma fereste cateodata de greseli. Incercati sa nu folositi un IDE cu debugging inclus (cum ar fi RHIDE sau Borland C++ 3.1). La inceput o sa va vina greu, dar va obisnuiti... si deveniti mai atenti cand scrieti surse. Puteti sa folositi Kate, un editor de text asemanator lui EditPlus de sub Windows. Vim este deasemenea un editor foarte puternic, dar pentru cine stie sa-l foloseasca.

h2. 1

h2. Pont #1

Impartiti programul dumneavoastra in functii, fiecare sa nu depaseasca mai mult de 30-50 de linii (aproximativ 2 ecrane ANSI 80x25). Este important sa aveti mereu o viziune asupra intregii functii. Regula este: complexitatea unei functii trebuie sa fie invers proportionala cu lungimea ei. Puteti sa declarati functiile "inline" (nu pe toate !) pentru a nu pierde din viteza.

h2. 2

h2. Pont #2

Macro-urile nu le recomand. Daca le folositi ca functii aveti grija. Unul dintre colegii mei de la lot a pierdut multe puncte pentru ceva asemanator.

}
==

h2. 3

h2. Pont #3

Cand accesati un element din memorie, procesorul citeste de fapt $32$ bytes (sau cat de mare e linia de cache, dar o putere a lui {$2$}). Recomand ca structurile voastre sa aiba de asemenea ca dimensiune o putere a lui $2$ pentru a nu forta procesorul sa citeasca de $2$ ori. O extensie GNU a standardului ANSI C sunt atributele. Pentru structuri, una din cele mai folosite (de mine) este packed ce instruieste compilatorul se nu mai adauge "padding bytes".

... functia s-ar fi executat de ~{$3$} ori mai repede (doar {$6.05$}s) iar rezultatul era acelasi. De ce? pentru ca in primul caz la fiecare accesare a $t[j][i]$ procesorul era nevoit sa acceseze memoria, iar in cazul al doilea cand citea {$t[i][j]$}, erau citite de fapt si {$t[i][j+1]$}, {$t[i][j+2]$}, {$t[i][j+3]$}. Si sa nu uitam viteza memoriei este mult mai mica decat cea a procesorului.

h2. 4

h2. Pont #4

Variabilele globale sa nu fie folosite in scop local. Daca as modifica functia astfel

... timpul de executie s-ar fi marit la {$6.44$}s. Nu e prea mult... dar se aduna.

h2. 5

h2. Pont #5

Stack-ul (locul unde se pastreaza toate variabilele locale) este foarte rapid. Modificam acelasi program astfel:

Utilizati si literele mari pentru anumite variabile mai importante (poate si macro-uri).

h2. 7

h2. Pont #7

O alta extensie GNU sunt "zero-length arrays". Se folosesc in general la skiplist-uri pentru a declara un array de dimensiune variabila intr-o structura.

bla *temp = (bla *)malloc(sizeof(bla) + no_levels*sizeof(bla *));
==

h2. 8

h2. Pont #8

h3. a

Pentru debugging folositi {$fprintf(stderr, ...)$}. Daca se intampla sa uitati, macar nu primiti "wrong answer" din cauza unui {$printf$}.

h2. 9

h2. Pont #9

h3. a

h2. 10

h2. Pont #10

Daca programati in C++ fara sa folositi STL incercati sa renuntati la C++. Unul dintre motive: clasele (implicit iostream: cin, cout, cerr) incetinesc mult executia programului.

h2. 11

h2. Pont #11

In final, o intrebare pentru cei ce folosesc C++ (asta e un hint). Cum se calculeaza factorial la compilare? (fara a scrie efectiv 1*2*3...*n)