Care e metoda platform specific, ca nu gasesc pe net. Doar oameni care spun sizeof(array)/sizeof(type).

PS: Cica exista o solutie after all, documentata de un tip pe un forum, si anume:

)

Pina si solutia aia e gresita, pentru ca n-o sa afli dimensiunea array-ului ci dimensiunea zonei de memorie din care face parte. Cu alte cuvinte, daca aloci 2 array-uri si incerci sa afli cit de mare e primul cu metoda aia, o sa afli cit de mari sint amindoua, plus inca un numar random de bytes. Page fault iei doar cind treci de marginea unei pagini alocate, nu a unui buffer returnat de alocatorul din CRT.

In general e o prostie sa vrei sa stii cit de mare e un buffer spre care ai doar un pointer. Daca te intereseaza asta trebuie sa primesti de la caller si dimensiunea, deoarece caller-ul stie. E o chestie de design al codului. O functie care are nevoie sa stie dimensiunea unui buffer si n-o primeste e prost facuta. Exemple notorii sint strcat(), strcpy(), sprintf() si asa mai departe, care nu stiu cit de mare e bufferul destinatie si sint sursa numarul unu de gauri de securitate din diversele softuri (in special alea micromoi mai vechi, cum ar fi IIS de acum 2-3 ani). Aia care au facut functiile astea au fost niste imbecili si din pacate si-au dat seama mult prea tirziu.

Daca buffer-ul e alocat dinamic, tine minte odata cu el cit ai alocat sau foloseste un container care face asta pentru tine, cum ar fi std::vector. Daca e alocat static (pe stiva, global etc.) stii din declaratie, asa ca zi-le si functiilor pe care le apelezi.

Dupa tot disclaimer-ul asta, exista metode platform-specific de a afla cit de mare e un buffer alocat dinamic. Trebuie sa stii cum merge alocatorul de memorie, sau sa iti dea niste functii care sa-ti expuna matele lui. In CRT-ul lui VC exista _msize(), in GLIBC exista malloc_usable_size(). Mare atentie insa, deoarece de exemplu malloc_usable_size() iti returneaza dimensiunea reala a buffer-ului, care nu-i intotdeauna egala cu dimensiunea pe care ai cerut-o tu (uneori e mai mare).

Sint putine lucruri mai abominabile decit sa folosesti functiile astea. De exemplu:



Dupa aia vine cineva si face:



Surpriza, "str" nu e alocat dinamic, deci _msize() nu stie nimic despre el. In al doilea exemplu, "a" este alocat dinamic, dar "str" e un membru al sau, deci din nou _msize() nu stie nimic despre el. N-ai de unde sa stii daca un pointer vine de pe stiva, de la malloc(), dintr-o structura mai mare etc. Din acest motiv _msize() si prietenii lui sint inutili. Nu-i folosi. Functia aia se poate scrie intr-un singur fel:



In felul asta il obligi pe caller sa-ti spuna explicit cit de mare e buffer-ul. Daca nu stie, inseamna ca si caller-ul a fost facut prost si trebuia sa primeasca si el un size in lista de parametri, si tot asa pina la virf unde e declarata sau alocata variabila.

Deci: nu exista metode de a afla cit de mare e un buffer spre care ai doar un pointer.

Acum sa revenim, cine se prinde cum functioneaza _countof()?

Parerea mea e sa tii si countul de elemente intr-un intreg, ca de-aia esti in C.
Eu n-as folosi chestii de tip countof, care incearca la runtime sa se uite prin cine stie ce locatii interne, dupa marimea zonei de memorie. Indiferent cine zice ca merg.
Iar daca vrei sa fii mai C++, fa-ti o clasa de array si tii countul ca membru acolo.

_countof nu incearca sa faca nimic la runtime si nici nu se uita prin nimic intern. Totul e compile-time si nu merge decit pe array-uri statice, in rest iti da compile error (in C++). E pentru chestii d-astea:



Este o idee deosebit de proasta sa scrii:



pentru ca cineva o sa vina si o sa schimbe numarul de elemente din params si n-o sa se uite in toate for-urile din program. E de asemenea pentru d-astea:



La fel ca si mai sus, e o prostie sa scrii direct 64, ca o sa ai probleme cind cineva schimba dimensiunea buffer-ului. Unii folosesc sizeof() aici, dar si ala e o prostie, pentru ca intr-o zi o sa descoperi ca vrei unicode, si atunci:



o sa te loveasca si n-o sa stii de unde. swprintf() doreste numarul de caractere disponibile in buffer, nu numarul de bytes. sizeof() e numarul de caractere doar cind caracterele au un byte. Daca scrii cu _countof() de la inceput scapi de dureri de cap.

Un neam si mai ascuns de probleme e in WINAPI, unde un define ascuns iti face toate string-urile unicode. Daca folosesti sizeof() acolo, cind cineva iti baga use Unicode o sa ai o groaza de cosmaruri despre buffer overflow-uri.

Concluzia: foloseste _countof(). Daca nu vrei sa te legi de CRT-ul Microsoft, copiaza definitia customizata de mai sus in PCH la tine si foloseste-o p-aia. Nu e negociabil.

Tocmai cand imi luasem si eu cateva zile libere...

Ah, iubesc sintaxa C++ Geniala faza, good laugh

Desigur, e doar in aparente, defapt e destul de simpla treaba:

Template-ul ul defineste o functie ce returneaza un pointer catre un array de char-uri. (De ce un pointer? Pt ca e ilegal sa returnezi un array direct!)

Template-ul se rezolva din tipul variabilei care il dai ca argument:

int a[19];

StaticArrayNumElemsHelper(a) rezolva la predeclaratia functiei:
StaticArrayNumElemsHelper(int un_array[19]);

'Type' e acolo in template pt ca nu are importanta care este tipul unui element din array, poate sa fie chiar si alt array (de ex daca 'a' ar fi fost int a[3][2], atunci _countof ar fi returnat 3, iar tipul lui a[0] este int[2]), dar trebuie sa fie acolo, pt ca variabila aia un_array trebuie sa aibe un tip, si cum nu conteaza care e, Type e in template; dar 19... aici e partea desteapta, trece in SizeOfArray, care este mai apoi folosit ca numarul de elemente din array-ul returnat de pointerul returnat de functia respectiva.

Type (&arr)[SizeOfArray] Asta e toata jmecheria. Daca argumentul, arr, nu e un array, template-ul nu se poate rezolva... pt ca arr trebuie sa fie un array de orice numar de elemente, de orice tip de element. Pt ca daca nu e, template-ul nu poate fi rezolvat. So yeah, un pic "wtf?".

/edit: un pic mai clar spus: arr este declarat ca o referinta la un array de un numar oarecare de elemente de un tip oarecare. Functia e un template care depinde de acele 2 oarecare-uri, asa ca o sa fie o functie (implementare) diferita pt orice combinatie diferita de acele oarecare-uri. Oricare ar fi acele oarecare-uri, arr ramane un array, asa ca nu poti sa ii dai argument altceva decat un array. Um, idea e ca totul e mai simplu decat pare. Pur si simplu 'este', nu-i nici-un voodoo shit la mijloc.

Apoi, partea cu sizeof din #define:
sizeof(*StaticArrayNumElemsHelper(x))

StaticArrayNumElemsHelper(x) aparent cheama functia respectiva. Defapt nu. Asta e doar sintaxa la sizeof pt a afla dimensiunea tipului returnat de o functie. (cum asta e compile time shit, se rezolva la compile time, deci no call)

Iar steluta aia * e pt a face derefencing la pointerul acela al tipului returnat, rezultand ca ramai cu ceva de genul sizeof(char[n]), care e egal cu n. E mereu char, pt ca nu conteaza ce e defapt. Ar fi putut returna Type in loc de char, dar chiar nu are nici o diferenta. Sper.

Toata treaba e facuta de compilator, static, la compile time...



Now where's my bonus points?!

Ok, primesti bonus points (pe care deocamdata le poti preschimba doar in stima si mindria Partidului ), cu o singura mentiune: tipul returnat trebuia sa fie array de char, nu putea fi array de T. Daca era T te intorceai de unde ai plecat. Trebuie sa fie array de char pentru ca in standard e specificat ca sizeof(char) = 1, si atunci sizeof(char[SizeOfArray]) = SizeOfArray, care e ce cauti. Daca era int[SizeOfArray] nu mai obtineai SizeOfArray.

Ah, in seara asta am mai aflat si de la ce vine litera aia "C" din C++... (in fundal: muzica din telenovele de atunci cand aflii Adevarul Socant™)



Pfft, ca de obicei, iar a intrat in efect talentul meu nemarginit de a o da in bara la cele mai marunte detalii ... Because I can!

bun articolu chiar o sa incerc