[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