On 16 Jan 2003, Raider wrote:
> Memory leaks.
Greseala programatorului.
> Buffer overflows.
Idem.
> Etc etc.
Asta e tot?! Sa inteleg ca din punctul tau de vedere, daca un limbaj
iti permite sa faci greseli, este el insusi "o mare greseala"...
Interesant. Parerea mea este insa ca nu s-a inventat (si e foarte
probabil sa nu se inventeze vreodata) limbajul in care sa nu se poate
scrie programe eronate/gresite. Daca tu il gasesti, te rog anunta-ma.
> Documenteaza-te inainte, ca doar impresiile nu isi au locul. Si
> vorbesti doar din impresii...
Nu eu am facut afirmatii in ceea ce priveste valabilitatea C-ului ca
limbaj, deci nu prea imi dau seama de ce as "vorbi din impresii". Il
folosesc de ceva vreme si nu cred ca ar fi un limbaj slab, dimpotriva.
Este foarte portabil, si destul de apropiat de masina incat sa nu te faca
sa te simti "intr-un turn de fildes", asa cum se intampla cu limbajele de
"nivel inalt". Pe langa acest lucru ar mai fi si faptul ca o foarte mare
parte a programelor si proiectelor de anvergura scrise in momentul de
fata folosesc acest limbaj si imi vine greu sa cred ca toti acesti oameni
folosesc "marea greseala" din prostie sau ignoranta...
> C++ nu are probleme de alocare a memoriei atita timp cit e C++ (si nu
> un oarecare cu prostul obicei de a combina C cu C++).
Ei nu zau?! Ia sa vedem... ce face urmatorul cod:
x = new cucu[100]; // cucu fiind o clasa oarecare ce foloseste
// macar o zona de memorie alocata dinamic
...
delete x;
Conform argumentului tau, C++ este o "mare greseala" din moment ce
permite astfel de lucruri...
> Si in cazul asta, programarea de la scoala nu prea ajuta.
Afirmatia asta nu prea o inteleg... ce ai vrut sa spui? Ai vreo
obiectie cu privire la sistemul de invatamant din Romania? Bine, sunt
sigur ca nu esti singurul... dar nu cred ca am adus in discutie acest
subiect in mesajul original.
> Trebuie sa stii tot timpul cit si unde. Altfel se cheama crappy
> programming si vine de la necunoasterea unor reguli de baza sau de la
> lucrat prea multe ore fara pauza.
Aha... eu zic sa mai citesti o data paragraful din mesajul original,
in care dadeam un exemplu de situatie in care este preferabil sa folosesti
datele care sunt deja acolo, din considerente de viteza si/sau spatiu
utilizat. Oricum, deja s-a raspuns la intrebare.
> > Pai stiu asta, numai ca nu am reusit sa-mi dau seama daca el retine
> > pe undeva si valoarea "exacta" ceruta de apel, sau doar pe cea care o
>
> Daca ceri o valoare, poti sa o stochezi undeva. Pentru ca regula in C
> este -1 pentru failed function. Atita vreme cit result != -1 ramine
> valabil cit i-ai dat. Toate functiile din familia *alloc lucreaza cu
> blocuri _continue_ de memorie. Punctul de start il ai in pointer (si nu
> il uiti niciodata pina la eliberarea cu succes a memoriei) si lungimea
> vectorului o ai de cind ai zis ca vrei (sau de la redimensionarea
> incheiata cu succes).
Nu ai inteles ce vroiam sa spun. Era o usoara deviatie de la
subiectul initial, in care ma intrebam daca se scrie undeva in
"header-ul" zonei alocate, pe langa memoria alocata, si cat a fost cerut
initial. Dar studiind ceva mai amanuntit malloc.c, nu e cazul (si nici nu
ar avea sens, de fapt, ar fi pierdere de memorie degeaba).
> Acum, hai sa te gindesti logic un moment - asta e functie (nu procedura
> de pascal). Deci introduci un numar N de parametrii, primesti un
> rezultat. Daca inceputul vectorului este dat (altfel nu ai putea lucra
> cu spatiul alocat), unde mai e loc de dimensiune?
Deci ce vrei tu sa spui este ca malloc() iti intoarce _un_singur_
parametru ca rezultat, si deci nu ar avea cum sa tina minte si cat i-ai
cerut? Eu zic sa te mai documentezi despre cum se face alocarea memoriei,
si dupa aceea sa revii. Ideea este ca valoarea respectiva poate fi stocata
inainte sau dupa (sau si inainte si dupa) zona alocata efectiv. Problema
este sa stii unde, si mai ales in ce format (de obicei sunt mai multe
informatii acolo, nu doar dimensiunea alocata, deci trebuie sa stii care
este cea cautata). Si cum implementarile difera de la libc la libc,
intrebarea mea initiala se referea la existenta unei functii care sa
interpreteze aceste date, si sa fie implementata in mai multe libc-uri cu
aceeasi denumire si comportament (desigur, cu implementare specifica
pentru fiecare caz in parte). Am aflat ca nu exista, si ca singurul mod
elegant de a rezolva problema este prin wrapper-e. End of story (de abia
aici).
Numai bine,
--
Mihnea-Costin Grigore [ "Tenebus Ipsilo Ibinem Catehens" ]
E-mail: [EMAIL PROTECTED] Home Page: http://mgc8.virtualave.net
---
Pentru dezabonare, trimiteti mail la
[EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'.
REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
