Tag Archives: cpp

[cpp] pointeri la functii membre unei clase

Uneori solutia de a defini o clasa noua derivata din una de baza pentru a defini un comportament (o functie) nu este chiar cea mai buna. De aceea, se poate opta si pentru lucrul cu pointerii catre functii, dar cu clasele + pointerii la functii e putin mai dificil datorita faptului ca exista un parametru ascuns… “this”

Continue reading [cpp] pointeri la functii membre unei clase

why STL sucks

Nu sunt mare fan al claselor din STL si niciodata n-am fost si asta din simplul motiv ca e greu sa te uiti peste sursele lui, de aceea multi nici nu o fac…. dar asta are cam consecinte grave ( cel putin pentru proiectul la care lucrez eu ).

Lucrez la un proiect in care incerc sa folosesc maxim din puterea de calcul a unui calculator cu 8 CPU-uri si ma gandeam eu asa ca ar fi ok sa paralelizez codul pe 8 thread-uri. Zis si facut.

Din cand in cand mai deschid eu task managerul sa vad cam cat putere de calcul suge aplicatia mea si… iaka ce vad

PS: kernelul este destul de stresat de aplicatie.

Per total, o aplicatie cu codul paralelizat, pe 8 threaduri suge aproximativ 30% din procesor…. am zis ca ceva nu e oki si am inceput sa debughez putin. Iaka ce imi zice visual studio:

deci: 1 thread pentru programul principal + 8 thread-uri. Se poate observa ca 5 thread-uri stau intr-o functie _Mtxlock. Deci… ce e cu functia asta? Arata astfel :

deci… mutex… ceea ce e rau la multithreading… Intrebarea? de unde atat de multi mutexi? Raspuns: niste call stackuri:

concluzie: toate lock-uri sunt din cauza claselor din STL : vector / map / list. Chiar daca sunt utilizate clasele doar intr-un singur thread, cel mai mult dureaza interogarea sistemului de operare (SO) care face lock-ul pentru mutex… si SO nu prea rezista la asa flux mare de mutexi…

Sfatul meu: a nu se utiliza stl, cel putin cand se vrea paralelizarea unui process.

Solutia pentru mine??? Cred ca trebuie sa incep sa scot pe rand cate o clasa de stl din cod.

8 metode de a reduce numarul bug-urilor atunci cand programati

Azi am dat peste un post interesant despre evitarea bug-urilor in timp ce programati. Originalul il gasiti aici.

Sunt interesante punctele de vedere ce le specifica autorul si de aceea vreau si eu sa le mentionez la mine pe blog, desi sunt unele noi care nu se aplica la programarea pe care eu o fac acuma in c/c++

  • Scrierea de teste unitare si teste de integrare. Principiul test – code – test mi se pare foarte bun si se aplica foarte bine la proiectele cu cod mult  si stufos. O data ce aveti un set consistent de teste veti fi mai siguri pe produsul care il creati. ( PS: am fost cel care a introdus testarea unitara in motoarele de antispam )
  • Use tools : singurul tool pe care il folosim este valgrind-ul si in rest testarea unitara si experienta de programare 🙂
  • Compiler warnings : e bine de a se elimina cat e posibil toate warning-urile. Ideea e ca atunci cand ai multe warning-uri (chiar si warning-uri simple ) printre ele se pot strecura warningur-uri ce pot genera diferite genuri de erori si, datorita faptului ca exista un volum mare de warning-uri, acestea sunt trecute cu vedere. Deci, eliminati pe cat de mult posibil warning-urile.
  • Code Review : e bine sa iti faca cineva code review peste codul tau, astfel afli mai multe despre codul scris de tine si de asemenea sa faci review pe codul scris de altcineva – poti invata diferite lucruri interesante din el.
  • Logs : no comment
  • Utilizarea librariilor existente – la prima vedere pare foarte costisitor datorita timpului pe care trebuie sa il pierzi pentru a integra libraria sau a citi documentatia, dar dupa ce treci de acesti 2 pasi o sa simti o satisfactie atunci cand poti sa combini mai multe tool-uri pentru a face ceea ce vrei tu si pe langa asta stii ca ai nishte librarii testeate/dezvoltate de altcineva.
  • Pseudo cod – depinde de proiect daca ai sau nu de acest pseudo cod. In general pentru incepatori e foarte util pentru ca isi dau seama de cazurile speciale inainte de a incepe sa scrie insusi codul, ceea ce ar putea duce la o modificare de design.
  • Evitarea distragerii atentiei – e o problema pe care putini o recunosc, dar care o au foarte multi ( asa cred eu! ). Chiar am sa citesc despre tehnicile precum pomodoro / rescuetime .

atat.