Cele mai importante cinci modificări de la VB 6 la VB.NET

Visual Basic 1.0 a fost un cutremur major în toată programarea. Înainte de VB1, trebuia să utilizați C, C ++ sau un alt mediu de dezvoltare oribil pentru a crea aplicații Windows. Programatorii au petrecut săptămâni întregi doar desenând ferestrele pe ecrane cu un cod captivant, detaliat, greu de depanat. (Același lucru pe care îl puteți face trăgând un formular din bara de instrumente în câteva secunde.) VB1 a fost un hit și gazillions de programatori au început imediat să-l folosească.

Dar pentru a face magia să se întâmple, Microsoft a făcut câteva compromisuri majore de arhitectură. În special, din moment ce VB1 a creat formularele și controalele, acestea nu au permis accesul programatorului la codul care a făcut-o. Fie lăsați VB să creeze totul, fie utilizați C ++.

VB 2 până la 6 a menținut aceeași arhitectură. Microsoft a făcut unele actualizări foarte inteligente, ceea ce le-a oferit programatorilor un control mult mai mare, dar în analiza finală, programatorii încă nu au putut integra codul lor cu codul VB. Era o cutie neagră - și nici în modul OOP bun. Un alt mod de a spune acest lucru a fost că programatorul nu a avut acces la "obiectele" VB interne și un alt mod de a spune că VB6 încă nu era complet "orientat pe obiect".

Între timp, au început să apară Java, Python și o mulțime de alte limbaje de programare orientate pe obiectul WERE. Visual Basic era treptat - timpul mare! Aceasta este o situație pe care Microsoft nu o tolerează... și au rezolvat să rezolve o dată pentru totdeauna problema. Soluția este .NET.

Dar pentru a face lucrurile pe care .NET trebuia să le facă, Microsoft a decis că trebuie să „spargă compatibilitatea”. Adică, programele Visual Basic au fost (cu excepții foarte mici) „compatibile ascendent” de la VB1 până la VB6. Un program scris în prima versiune de VB va fi în continuare compilat și rulat în următoarea versiune. Însă, cu VB.NET, Microsoft a descoperit că nu reușeau să facă limba complet OOP și să mențină compatibilitatea ascendentă.

Odată ce au luat această decizie fundamentală, porțile de inundații s-au deschis pe zece ani de modificări acumulate de „lista dorințelor” și TOATE acestea au intrat în noul VB.NET. După cum se spune în Marea Britanie, „În pentru un ban, în pentru o liră”.

Fără întârziere, iată lista mea personală a primelor cinci modificări de la VB6 la VB.NET în ordine inversă.

Wellllll... doar o altă întârziere. De când ne schimbăm de la VB6, unde un tablou a fost declarat Dim myArray (5) are 6 elemente, Avem șase dintre ei. Este potrivit doar ...

(Tamburul vă rog ...)

„Premiu (5)”, al nostru Locul 6 premiul merge la alegerea grupelor C: Modificări de sintaxă asemănătoare lui C!

Acum puteți codifica a + = 1 în loc de a = a + 1, economisind TREI CĂTRE TIPURI CHEIE!

Programatori ai lumii, Bucură-te! VB a fost ridicată până la nivelul C și o generație cu totul nouă, care încearcă să învețe VB, se va apropia puțin de confuzia de masă care se confruntă cu studenții C ++.

Dar asteapta! Mai este!

VB.NET prezintă acum „logica de scurtcircuit” care a introdus de ani buni bug-uri subtile în codul C ++ pentru a economisi prețioase nano-secunde de timp a procesorului. Logica de scurtcircuit evaluează doar condițiile multiple într-o enunțare logică, dacă este necesar. De exemplu:

Dim R Ca Boolean
R = funcție1 () și funcție2 ()

În VB6, ambele funcții sunt evaluate dacă au nevoie sau nu. Cu VB.NET, dacă Function1 () este fals, Function2 () este ignorat deoarece „R” nu poate fi True. Dar ce se întâmplă dacă o variabilă globală este modificată în Function2 () - doar din întâmplare (programatorii C ++ ar spune „prin programare slabă ".) De ce codul meu produce un răspuns greșit o parte din perioada în care este tradus în VB.NET? Este posibil să fie!

Pentru ÎncercaVB.NET va fi mai greu Captură putin noroc si In cele din urma obțineți recunoaștere pentru gestionarea erorilor „excepționale”.

VB6 a avut ultima opțiune GoTo: „On Error GoTo”. Chiar și trebuie să recunosc că manipularea structurată a excepțiilor în stilul C ++ „Try-Catch-Final” este o îmbunătățire vastă, nu doar o îmbunătățire pe jumătate vastă.

Ce, spuneți „On Error GoTo” este încă în VB.NET? Wellll... Încercăm să nu vorbim prea mult despre asta.

Locul 5 selecția este un premiu de grup: Comenzile diverse se schimbă! Trebuie să împărtășească acest premiu și există o serie de oameni. Microsoft a economisit timp de zece ani și au tăiat cu adevărat.

VB.NET nu mai acceptă funcțiile VarPtr, ObjPtr și StrPtr care au preluat adresa de memorie a variabilelor. Și nu acceptă VB6 LSet care a fost folosit pentru a converti un tip definit de utilizator în altul. (Nu trebuie confundat cu VB6 LSet, care face ceva complet diferit - vezi mai jos.)

De asemenea, oferim un adept al companiei Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar și GoSub (favoritul meu personal!).

Cercul s-a transformat în GDI + DrawEllipse. Același lucru este valabil și pentru Line to DrawLine. În calcul, acum avem Atan în loc de Atn, Sign in merge la Sgn, iar Sqrt se potrivește pentru jocul mare în loc de Sqr.

În procesarea șirurilor, chiar dacă acestea sunt încă disponibile dacă faceți referință la o compatibilitate Microsoft nume de spațiu, avem PadRight pentru LSet-ul VB6 (din nou, total diferit de VB6 LSet, desigur) și PadLeft pentru RSet. (Există cele trei apăsări de taste pe care le-am salvat cu „+ =”!)

Și, desigur, din moment ce suntem OOP acum, nu vă preocupați dacă setul de proprietăți, proprietatea de proprietate și proprietatea de primire nu sunt îndeplinite în VB.NET, pariați!

În cele din urmă, Debug. Tipărirea devine fie Debug. Scrie sau Debugează. WriteLine. Doar tocilarii tipăresc totul oricum.

Acest lucru nici măcar nu atinge toate comenzile NOU din VB.NET, dar trebuie să oprim această prostie undeva.

În Locul 4, noi avem Modificări la apelurile de procedură!

Acesta este premiul „bunătatea, puritatea și virtutea sănătoasă” și reprezintă o mulțime de campanii dure din partea fracțiunii „Fără cod mai sloppy”.

În VB6, dacă o variabilă a parametrului de procedură este un tip intrinsec, atunci este ByRef, cu excepția cazului în care ați codat-o ByVal explicit, dar dacă nu este codificat ByRef sau ByVal și nu este o variabilă intrinsecă, atunci este ByVal... Am inteles?

În VB.NET, este ByVal dacă nu este codat ByRef.

Apropo, ByVal VB.NET, de asemenea, împiedică modificările la variabilele parametrilor în proceduri să fie propagate în mod neintenționat în codul de apel - o parte cheie a unei bune programări OOP.

De asemenea, Microsoft „supraîncarcă” VB.NET cu o modificare a cerințelor pentru paranteze în apelurile de procedură.

În VB6, parantezele sunt necesare în jurul argumentelor atunci când efectuați apeluri funcționale, dar nu atunci când apelați o subrutină atunci când nu utilizați instrucțiunea Apel, ci sunt necesare atunci când este utilizată instrucțiunea Apel.

În VB.NET, parantezele sunt întotdeauna necesare în jurul unei liste de argumente nonempty.

Premiul Bronz - Locul 3, se duce la Schițele sunt bazate pe 0 în loc de 1 bazate!

Este doar o schimbare de sintaxă, dar această schimbare primește statutul de „podium de medalii”, deoarece este votată, „cel mai probabil să îți înnobilăm logica programului”. Amintiți-vă, locul 3 ESTE „Premiu (2)” din lista noastră. Dacă aveți contoare și tablouri în programul VB6 (și câți nu), acesta va MESS YOU UP.

Timp de zece ani, oamenii întreabă: „Ce fumează Microsoft când o făceau așa?” Și de zece ani, programatorii au un fel de universal a ignorat faptul că a existat un element myArray (0) care a ocupat doar spațiul și nu s-a obișnuit orice... Cu excepția programatorilor care îl folosesc și programele lor arătau, adică doar „ciudat”.

Pentru I = 1 la 5
MyArray (I - 1) = Orice
Următor →

Vreau să spun, ÎNTR-ADEVĂR! ...

Medalia de argint din Locul 2 merge să onoreze un vechi prieten care a fost aruncat în găleata de programare odată cu trecerea VB6! Nu vorbesc despre nimic altceva decât, Tipul de date al variantei.

Probabil că nici o altă caracteristică unică a Visual Basic „notNet” nu reprezintă mai bine filozofia „rapid, ieftin și liber”. Această imagine a perceput VB până la introducerea VB.NET. Sunt suficient de bătrână pentru a-mi aminti introducerea Visual Basic 3.0 de către Microsoft: „Oh, uau! Uite aici! Cu noul tip de date Variant îmbunătățit, nu trebuie să declarați variabile sau nu. Puteți doar să le gândiți și să le codificați. "

Microsoft și-a schimbat tonul destul de repede pe acela și a recomandat declararea variabilelor cu un tipul de date specific aproape imediat, lăsând pe mulți dintre noi să ne întrebăm: „Dacă nu puteți utiliza Variante, de ce le am?"

Dar, în timp ce suntem pe tema tipurilor de date, ar trebui să menționez că multe tipuri de date s-au schimbat pe lângă faptul că a aruncat varianta în ciment umed. Există un nou tip de date Char și un tip de date Long care este de 64 de biți. Zecimal este mult diferit. Scurt și Integer nu mai au aceeași lungime.

Și există un nou tip de date „Obiect” care poate fi orice. Am auzit pe cineva spunând: "Fiul variantei"?

In cele din urma! Medalia de aur, locul 1, cel mai mare premiu pe care mi-l pot acorda merge la ...

TA DAH!

VB.NET este în sfârșit complet orientat pe obiecte!

Acum, când mergeți la plajă, programatorii C ++ nu vă vor lovi nisip în față și vă vor fura (iubita / iubitul - alegeți unul). Si tu poti încă codează un bilanț complet general de testare a înregistrărilor în timp ce încearcă să-și dea seama ce fișiere de antet să includă.

Pentru prima dată, puteți coda cât mai aproape de cip, cât trebuie și accesați toate sistemele interne pe care le doriți fără trebuind să apeleze la acele apeluri uriașe API Win32. Aveți moștenire, supraîncărcarea funcțiilor, multithreading asincron, colectarea gunoiului și Tot este un obiect. Viața poate fi mai bună?

Am auzit că cineva spune că C ++ are moștenire multiplă și .NET încă nu?

Arde ereticul!