Vb6 limbaj performant?
Daca ai ajuns sa intrebi
VB6 limbaj performant?inseamna ca te aflii intr-un impas. Nu conteaza asha mult cat de “performant” este limbajul de programare ci conteaza cat de talentat eshti in a-tzi transpune cunoshtintzele intr-un proiect cu ajutorul acelui limbaj.
De ce zic treaba asta ?
Pentru ca sa ajuns astazi ca nivelul limbajelor de programare sa fie aproximativ egal (… vezi platforma .NET) shi itzi ofera la aproximativ aceleashi solutzii doar ca modul de a le accesa sunt diferite. Shi de aici rezulta “calitatea” unui limbaj de programare.
dupa parerea voastra , Visual Basic 6 vi se pare la fel de performant ca si Visual C++ ?
Nu sunt un sustinator infocat al acestui limbaj, si nici nu lucrez frecvent cu el, dar am lucrat. Si pot sa va spun ca in ciuda faptului ca pare “total uncool” si pentru unii chiar “rusinos” sa spuna ca au facut un proiect in Visual Basic 6, eu consider ca aceste impresii sunt nejustificate.
Contrar parerilor multora dintre voi, Visual Basic este un limbaj foarte productiv. De ce spun asta? Pentru ca, la fel ca si Java, face parte din categoria limbajelor memory-managed. Asta inseamna ca nu trebuie sa-ti faci griji referitor la alocarea si dealocarea memoriei, managementul memoriei este facut automat. Si asta inseamna productivitate crescuta. Sunt multe exemple de cod care poate sa ia o pagina in C++ si cateva linii in Visual Basic.
twins
Contrar parerilor multora dintre voi, Visual Basic este un limbaj foarte productiv.
Nici eu nu am lucrat in VB, dar nu pot decat sa ma intreb: eliminarea erorilor de memorie este o latura a productivitatii. Dar cum ramane cu celelalte? Scalabilitate, usurinta de extindere a aplicatiei, usurinta cu care faci aplicatii complexe (care necesita clase multe si complicate)? Sunt si astea laturi ale productivitatii atunci cand gandesti pe termen lung.
Din auzice, VB are deficiente la capitolele astea.
Daca e din auzite… atunci se intelege de unde concluziile astea. Cred ca este “Basic”-ul din nume care da impresia unui limbaj mai putin demn de luat in seama.
Da… ar fi ceva. Visual Basic este un limbaj orientat-obiect. Un dezavantaj este ca pana la versiunea .NET nu a fost un limbaj complet orientat-obiect. Adica, din cele patru concepte necesare (abstractizare, polimorfism, inclapsulare, mostenire) pentru ca un limbaj sa fie orientat-obiect complet, pana la .NET Visual Basic nu a suportat decat trei din ele, lipsind conceptul de mostenire.
nu stiu ce sa zic in legatura cu alocarea si eliberarea memoriei…mie mi se pare ca aici VB-ul sta prost(vb6).lucrez de atata timp cu vb6 si am observat ca in momentul in care o fereastra are proprietatea windowstate=1(adica minimize) ea ramane in memorie , fapt ce nu se intampla in Delphi de ex.
lakelake
nu stiu ce sa zic in legatura cu alocarea si eliberarea memoriei...mie mi se pare ca aici VB-ul sta prost(vb6).lucrez de atata timp cu vb6 si am observat ca in momentul in care o fereastra are proprietatea windowstate=1(adica minimize) ea ramane in memorie , fapt ce nu se intampla in Delphi de ex.
...nici pe departe :unamused:
atunci de ce arata Task Managerul din WinXp aceeasi valoare a memoriei in modul minimize???
Acelasi lucru se intampla si in Delphi. Daca vrei sa faci teste cu SystemMonitor (eventual cel din TaskManager) ai grija sa faci de atatea ori cat este necesar sa se stabilizeze. Vei observa ca nu se elibereaza / re-aloca nimic.
Mai mult decat atat, este cat se poate de logic sa se intample asa. A spune ca “se elibereaza memoria cand dai minimize la fereastra” este echivalent cu a spune ca aplicatia / fereastra dispare din memorie. Pai si atunci cand dau restore de unde o ia? Nu trebuie sa fie stocata undeva? Doar nu o creaza din nou !?! 
Si oricum, falsa problema invocata nu se leaga in nici un fel de garbage-collectors si caracteristicile limbajelor memory-managed despre care se discuta mai devreme.
Deci faza cu “aici VB6-ul sta prost” nu se poate baza pe un astfel de argument, chiar daca ai lucrat mult in el.
te contrazic un pic.sa instalezi si tu un program pt eliberarea memoriei.sa vezi ce se intampla cand eliberezi memoria.sunt de acord ca nu se poate sa se elibereze memoria de tot cand ii dai minimize pt ca programul ala trebuie sa ramana undeva stocat dar totusi ce se intampla cu winampul la minimize… cum fac cei de la nullsoft sa elibereze memoria la minimize?
vad ca tii foarte mult sa ma contrazici.
as I said before - daca faci astfel de teste nu uita sa le repeti de suficiente ori incat sa se stabilizeze sistemul. pentru ca ai tinut neaparat sa ma contrazici, am facut si eu un test 
si, intr-adevar, NU se elibereaza memorie cand dai minimize (si nici nu ar trebui!). convinge-te si tu. eu am folosit system monitor. btw… ai sa observi ca indicatorul de memorie libera flucteaza constant cu o amplitudine de cateva sute de kbytes. cateodata chiar scade cand dai minimize si creste cand dai restore.
in cazuri extreme, si eu pot face o aplicatie care aloca si elibereaza memorie in functie de windowstate. dar asta e treaba mea, nu a VB-ului. mai mult decat atat, VB trebuie sa-mi dea acces la obiectele de pe form chiar si atunci cand formul e minimizat. ce memorie vrei sa eliberezi ? <br> <br>in orice caz... de la "VB6 e prost la capitolul memorie" si pana la "de ce winamp-ul elibereaza memorie la minize?" e cale lunga si intoarsa... asa ca oricum ma astept sa ma contrazici inca "un pic" si inca "un pic". :laughing: but thats ok… nu ma astept (si nici nu ar trebui) sa te conving ca am dreptate. 
noi sa fim sanatosi!
wickedman si tu ai vreo 800 de pitici?! 
Faza ca se elibereaza niste memorie cand minimizezi winamp-ul chiar merge 
. Spun asta ca am verificat acum cateva minute.
Nu ma pricep la soft, dar asta este probabil ca nu mai este apelat visual plugin-ul ala.
Anyway… treaba aia a mers. S-a redus de la 5 mb la 2.5 mb minimizat.
Toata interfatza winamp-ului este formata din bitmap-uri iar in momentul in care dai minimize programul elibereaza memoria de aceste bitmap-uri urmand ca la restore programul sa invoce functzia “redraw” a ferestrei iar bitmap-urile sunt incarcate iar. Dar … “de la VB6 shi pana la winamp este cale lunga shi intoarsa”.
BlackKiss
Toata interfatza winamp-ului este formata din bitmap-uri iar in momentul in care dai minimize programul elibereaza memoria de aceste bitmap-uri urmand ca la restore programul sa invoce functzia "redraw" a ferestrei iar bitmap-urile sunt incarcate iar. Dar ... "de la VB6 shi pana la winamp este cale lunga shi intoarsa". :smiley:
BlackKiss... Cred ca nu stii despre ce vorbesti.
Eu incercam sa zic ca la minimalizare winamp-ul descarca partea grafica de care nu mai are nevoie … daca cei de la nullsoft se respecta winamp-ul ar trebui sa shtie asha ceva.
Daca nu am dreptate te rog lamureshte-ma.
BlackKiss
daca cei de la nullsoft se respecta winamp-ul ar trebui sa shtie asha ceva.
Daca nu am dreptate te rog lamureshte-ma.
de ce sa descarci 256Kb de bitmap`uri din memorie pentru ca sa le incarci din nou de fiecare data cand dai restore (incarcarea se face de pe harddisk, skin`ul e stocat intr`un format special, eventual si zip-at) !??
cateodata e mai "scumpa" procesarea informatiei decat stocarea ei.
"iar daca cei de la nullsoft se respecta ar trebui sa stie asa ceva"
deci pana la urma eu cred ca este vorba de libajul in care este programat winampul adica c++
winampul este doar un exemplu.cel mai bine te lamuresti cand faci o fereastra care nu contine nimic in vb apoi aceeasi fereastra o faci si in delphi.le minimizezi pe amandoua si vezi ce se intampla.sa vezi ca am dreptate.si aici nu mai e vorba de partea grafica(skin).
BlackKiss
Eu incercam sa zic ca la minimalizare winamp-ul descarca partea grafica de care nu mai are nevoie .... daca cei de la nullsoft se respecta winamp-ul ar trebui sa shtie asha ceva.
Daca nu am dreptate te rog lamureshte-ma.
Deci tu stii sau presupui? Si ce vrei sa spui prin "descarca partea grafica de care nu mai are nevoie"? Poate vorbim despre lucruri diferite. La ce te referi? Ce descarca?