[CSProjects] More on static functions

Razvan Deaconescu razvan at anaconda.cs.pub.ro
Tue Jun 19 09:50:22 EEST 2007


Vlad Dogaru wrote:
> Razvan Deaconescu wrote:
>> Nu ai ce sa-i faci, asa merge C-ul. Poate ca exista niste extensii GCC 
>> care sa previna exportarea functiilor intr-un alt modul decat al tau, 
>> dar nu stiu despre ele. Cat timp tu vei expune doar un set de functii in 
>> spreadconv.h, te poti baza pe 'bunul simt' al utilizatorului bibliotecii 
>> ca le va folosi _doar_ pe acelea. Daca nu, asta e treaba lui :-)
> 
> OK, asta e clar acum, mai ales ca m-am jucat si eu cu ele intre timp. 
> Scapasem din vedere exemplul anterior, desi ni l-ai aratat si la USO.
> 
> Intrebarea acum este: mai adaug "spreadconv_" si in fata functiilor 
> astora auxiliare? Ele oricum ajung la nume suficient de obscen de lungi 
> si de criptice incat sa fie practic imposibil sa cauzeze coliziuni:
> 	add_unique_rc_style
> 	create_manifest_file
> 
> Mai are vreun rost sa le prefixez la fel ca pe cele pe care _vreau_ sa 
> le exportez?

Nu, nu are rost. Tine de preferintele tale. In general eu prefixez 
functiile specifice unui modul cu un acelasi prefix indiferent daca sunt 
sau nu statice.

Uita-te, spre exemplu, in modulul de kernel Linux de aici: 
http://lxr.linux.no/source/fs/bio.c#L447
Dupa cum vezi, chiar daca unele functii sunt statice, tot incep cu bio 
(bio fiind structura fundamentala de prelucrare).

In cazul tau, in schimb, nu stiu daca are sens sa prefixezi functiile 
statice cu spreadconv_, intrucat nu cred ca se leaga toate de structura 
spreadconv. Cele care prelucreaza direct aceasta structura ar trebui sa 
fie prefixate, indiferent daca sunt statice sau nu. Cele care fac 
altceva nu ar trebui sa aiba legatura. Cam asta este parerea mea.

Principial, nu exista o regula de aur. Solutia este sa te uiti prin 
sursele 'profesioniste' (cum m-am uitat eu in cele ale kernel-ului 
Linux) si sa-ti formezi o parere.

Razvan



More information about the cspay-dev mailing list