[so] [Tema3][Linux] fisier executabil

[Paul Olaru]

Globalele sunt o problemă în proiectele mari pentru că este mai dificil să
vezi ce cod le folosește. Și pentru majoritatea situațiilor la care mă
gândesc (INCLUSIV cea din tema asta) mă gândesc că o variabilă globală
limitată (sau statică per clasă) este suficient -- elimină problema
efectelor secundare fără a îngreuna utilizarea codului în sine. Mai ales că
suntem single threaded și nu e nevoie nici măcar de sincronizare, în
situația de față variabilele globale (cu static) sunt chiar ok. Recomand
'static' acolo pentru ca alte module să nu modifice imprevizibil variabila.

Un global global fără nicio restricție e ok în proiecte până în 1000-2000
de linii după părerea mea (sau proiecte mai mari dacă e mult boilerplate;
ideea e ca întregul cod să încapă în mintea unei singure persoane) dar în
acelea care sunt mai mari, sau vor deveni pe viitor mai mari, pot deveni o
problemă dacă le folosești fără un motiv bun. Zic că complică procesul de
debug pentru că există posibilitatea să existe multe accese la aceeași
variabilă globală. Soluția cu 'static' rezolvă chestia asta în cele mai
multe situații -- rareori e o restricție reală.

On Mon, Apr 15, 2019, 12:36 PM Mihai Barbulescu via so <so at cursuri.cs.pub.ro>
wrote:

> Salutare tuturor,
>
> In completarea maestrului RD eu unul chiar incurajez in situatii
> extreme/in situatii in care nu se pot evita atat folosirea goto cat si
> folosirea variabilelor globale.
>
> Exemple de folosire a variabilelor globale pe langa cel de care tocmai
> v-ati lovit (si este OK si __IN REGULA__ sa folositi globala) ar fi sa
> aveti un state machine asupra caruia umbla mai multe threaduri (sau
> nu) - de ex pt a stii starea curenta (daca ai threaduri faci accesul
> "sincronizat").
>
> Un exemplu de folosire goto aveti chiar pe wiki pentru eliberarea
> resurselor [1]. Acest approach e foarte important in lucrul cu
> dispozitive embedded pentru ca puteti lasa intregi resurse hardware
> marcate ca "ocupate" aiurea
>
> Paul Olaru: as vrea si o justificare pentru afirmatia "E bine să nu ai
> mai multe globale decât este necesar (complică mult procesul de
> debug)." - ce inseamna ca procesul de debug e complicat? Debuggerul
> stie sa arate si variabilele globale, de-aia fiecare proces are acea
> zona de memorie pt globale (.data si .bss) si poti debuga continutul
> lor prin breakpoint si inspectand acele zone de memorie ca sa fii
> sigur. E complicat procesul de debug ca trebuie sa te uiti in "inca o
> zona de memorie"? Raspunsul meu e NU, asta vine doar din
> lene/necunoastere.
> Stiu paper-ul la care te gandesti - ca sa nu ai side effects sau alte
> probleme de care zice acolo inseamna doar sa scrii codul cu ceva mai
> multa grija, lucru care oricum ar trebui sa va intre in reflex.
>
> Ah, da, la SD daca aveti de implementat lucrul pe o lista inlantuita
> si declarati o globala pt structura lista inlantuita ca sa scrieti
> functii cu cat mai putini parametrii sunteti noobs, de-aia va
> interzice la SD sa faceti asemenea abominatii. Dar este, asa cum a zis
> RD, o recomandare/guideline care admite exceptii.
>
> Sper c-am reusit sa demontez fake news-ul conform caruia globalele
> sunt diavolul pe pamant....Sunt o unealta asa cum e si tesla si
> trebuie sa ai grija sa nu iti dai cu ea in ... stiti voi continuarea.
>
> [1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die#alta_abordare
>
>
>
> On Sun, 14 Apr 2019 at 22:59, Razvan Deaconescu via so
> <so at cursuri.cs.pub.ro> wrote:
> >
> > "Alexandru-Ionuţ MÎNDRU (87849)" via so <so at cursuri.cs.pub.ro> writes:
> > > Eu cel puțin știu de la PC/SD din anul 1, nu mai știu exact care
> > > dintre cele 2. Era regula pentru teme să nu se folosească variabile
> > > globale, se scădea puncte pe treaba asta, fără a se explica de ce e
> > > greșit sau de ce să nu le folosim.
> >
> > Well, there's your problem.
> >
> > > Chiar și acum la tema 1 la PC spre exemplu, există această regulă.
> >
> > O să discutăm cu cei de acolo.
> >
> > > Cei drept acum nu am verificat strict pentru SO dacă există această
> > > regulă, dar am rămas cu acest lucru și presupun că și alții.
> >
> > Există reguli și există recomandări. Regulile sunt foarte puține (citat
> > aproximativ Jack Sparrow). În dezvoltarea aplicațiilor sunt foarte
> > puține "golden rules". Luați recomandările, țineți-vă de ele, dar
> > admiteți când e o prostie să te ții de ele cu dinții doar pentru că "așa
> > e bine".
> >
> > Exemple de recomandări, nu reguli, au excepții
> >
> > * Nu folosiți variabile globale.
> >
> > * Nu folosiți goto.
> >
> > * Puneți funcțiile deasupra main-ului.
> >
> > * Folosiți thread-uri, operații asincrone, expresii regulate, semnale.
> >
> > * Faceți codul portabil.
> >
> > Exemple de reguli sau lucruri care sunt mereu bune (nu știu să aibă
> > excepții în afara unor concursuri de genul "Obfuscated C contest").
> >
> > * Să fie codul consecvent. Prost dar consecvent prost decât bine în n
> >   feluri.
> >
> > * Variabile și funcții denumite cu cap, nu tmp_var, do_stuff, my_var.
> >
> > * Defensive programming: "Always code as if the guy who ends up
> >   maintaining your code will be a violent psychopath who knows where you
> >   live".
> >
> > * Trecut codul prin verificatoare statice și dinamice.
> >
> > * Făcut recenzie la cod.
> >
> > Răzvan
> > _______________________________________________
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
>
> --
> Cu stimă,
> Mihai Bărbulescu
> _______________________________________________
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20190415/356b661d/attachment-0001.html>