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 _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
