[so] [Tema 3] Extindere funcții wrapper

[Călin Cruceru]

Salutare,

Legat de partea în care se menționează că suntem încurajați să
extindem fișierele common.h și common_lin/win.c cu wrappere proprii:
părerea mea e că exprimarea asta lasă de înțeles că ar trebui să luam
fișierele (atât headerul _cât și implementarea_) și să adăugăm noi
declarații de wrappere și implementările lor, ceea ce e riscant și
chiar bad practice, cred.

Este riscant pentru că în felul acesta am avea toate funcțiile
implementate de 2 ori în momentul linkării executabilului generat de
framework-ul de testare: odată în shared library și odată din
common_lin/win.o compilat de framework.  Astfel că dacă vrei la un
moment dat să modifici unul din wrapperele _deja implementat_, o să ai
surpriza că nu se apelează implementarea ta, ci cea din
common_lin/win.o, din motive pe care nu pot să spun că le înțeleg prea
bine.  Poate aduce cineva clarificări legat de asta?  De ce preferă
linkerul implementările din obiecte, decât cele din shared library?
Am găsit ceva asemănător cu asta, dar totuși nu e aceeași situație[1].

Modul de organizare corect în cazul acesta, cred că este următorul: se
include common.h (cel din framework-ul de testare) din alt fișier
header - să-i zicem lib_wrappers.h - și se adaugă în lib_wrappers.h
declarațiile noilor wrappere iar in lib_wrappers.c definițiile lor.
Și peste tot în implementarea lib-ului vom folosi lib_wrappers.h.  În
felul acesta ne asigurăm prin design că suntem API compliant cu
framework-ul de testare și nu avem mai multe definiții cu același
nume.

PS: Dacă sunt singurul care a înterpretat inițial exprimarea din enunț
în felul acesta, ignorați acest e-mail.

PSS: Evident că o întrebare legit e "de ce ai modifica funcțiile
existente?"; un răspuns la fel de legit e "debugging".  Dar oricum,
asta nu schimbă flaw-ul în design.

[1]: http://stackoverflow.com/questions/6538501/linking-two-shared-libraries-with-some-of-the-same-symbols

Toate bune,
Călin