De fem øverste ændringer fra VB 6 til VB.NET

Visual Basic 1.0 var et stort jordskælv gennem programmeringen. Før VB1 var du nødt til at bruge C, C ++ eller et andet forfærdeligt udviklingsmiljø til at oprette Windows-applikationer. Programmerere brugte bogstaveligt talt uger på kun at tegne vinduer på skærme med betyder, detaljeret, svært at fejlsøge kode. (Det samme kan du gøre ved at trække en formular fra værktøjslinjen på få sekunder.) VB1 var et hit, og gazillioner af programmerere begyndte straks at bruge den.

Men for at få magien til at ske, kom Microsoft med nogle store arkitekturkompromiser. Da VB1 oprettede formularerne og kontrollerne, gav de ikke programmereren adgang til koden, der gjorde det. Du lod enten VB oprette alt, eller du brugte C ++.

VB 2 til 6 opretholdt den samme arkitektur. Microsoft foretog nogle meget smarte opdateringer, som gav programmører meget mere kontrol, men i sidste ende kunne programmerere stadig ikke integrere deres kode med VB-koden. Det var en sort kasse - og heller ikke på den gode OOP-måde. En anden måde at sige dette på var, at programmereren ikke havde adgang til de interne VB "objekter", og en anden måde at sige det på var, at VB6 stadig ikke var fuldt "objektorienteret".

I mellemtiden begyndte Java, Python og en hel masse andre programmeringssprog, der VAR objektorienteret, at vises. Visual Basic blev vedtaget - big time! Dette er en situation, Microsoft ikke tåler... og de besluttede at løse problemet en gang for alle. Løsningen er .NET.

Men for at gøre de ting, som .NET skulle gøre, besluttede Microsoft, at de skulle "bryde kompatibilitet". Det vil sige, Visual Basic-programmer var (med meget mindre undtagelser) "opad kompatible" fra VB1 helt op til VB6. Et program skrevet i den første version af VB vil stadig kompilere og køre i den næste version. Men med VB.NET fandt Microsoft, at de bare ikke kunne gøre sproget helt OOP og opretholde kompatibilitet opad.

Da de først havde taget denne grundlæggende beslutning, åbnede oversvømmelsesporterne ti år med akkumulerede "ønskeliste" -ændringer, og ALLE af dem gik ind i det nye VB.NET. Som de siger i Storbritannien, "In for a penny, in for a pund."

Uden yderligere forsinkelse er her min meget personlige liste over de fem bedste ændringer fra VB6 til VB.NET i omvendt rækkefølge.

wellllll... bare en yderligere forsinkelse. Da vi skifter fra VB6, hvor en matrix erklæres som Dim myArray (5) har 6 elementer, Vi har seks af dem. Det er kun passende ...

(Trommerull venligst ...)

"Award (5)", vores 6. plads prisen går til C groupies valg: C-lignende syntaksændringer!

Nu kan du kode a + = 1 i stedet for a = a + 1 og gemme TRE HELE TASTSTYRKE!

Verdens programmører, glæde sig! VB er hævet op til C-niveau, og en helt ny generation, der prøver at lære VB, vil komme lidt tættere på den masse forvirring, der konfronterer studerende på C ++.

Men vent! Der er mere!

VB.NET har nu "kortslutningslogik", der har introduceret subtile bugs i C ++ -kode i årevis for at spare dyrebare nano-sekunder processortid. Kortslutningslogik evaluerer kun flere forhold i en logisk erklæring om nødvendigt. For eksempel:

Dim R Som boolsk
R = Funktion1 () Og Funktion2 ()

I VB6 evalueres begge funktioner, om de har brug for det eller ej. Med VB.NET, hvis funktion1 () er falsk, ignoreres funktion2 (), da "R" ikke kan være sandt. Men hvad nu hvis en global variabel ændres i Funktion2 () - bare ved en tilfældighed (C ++ programmerere ville sige, "af dårlig programmering ".) Hvorfor giver min kode det forkerte svar noget af det tidspunkt, når det er oversat til VB.NET? Dette kan være det!

Til Prøveing hårdere, vil VB.NET Fangst lidt held og Endelig blive anerkendt for "usædvanlig" fejlhåndtering.

VB6 havde den sidste holdout GoTo: "On Error GoTo". Selv jeg må indrømme, at C ++ -stilen "Try-Catch-Endelig" struktureret undtagelseshåndtering er en enorm forbedring, ikke kun en halv enorm forbedring.

Hvad, siger du "On Error GoTo" er stadig i VB.NET? Wellll... Vi prøver ikke at tale for meget om det.

5. plads udvælgelse er en gruppepris: Diverse kommandoer ændres! De skal dele denne pris, og der er en gazillion af dem. Microsoft har sparet op i ti år, og de skød virkelig løs.

VB.NET understøtter ikke længere VarPtr-, ObjPtr- og StrPtr-funktioner, der hentede hukommelsesadressen til variabler. Og det understøtter ikke VB6 LSet, som blev brugt til at konvertere en brugerdefineret type til en anden. (Ikke at forveksle med VB6 LSet, der gør noget helt andet - se nedenfor.)

Vi byder også godt på at lade, mangler, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar og (min personlige favorit!) GoSub.

Cirkel er blevet omdannet til GDI + DrawEllipse. Det samme gælder Line to DrawLine. I beregningen har vi nu Atan i stedet for Atn, Sign går ind for Sgn, og Sqrt passer til det store spil i stedet for Sqr.

I strengbehandling, selvom de stadig er tilgængelige, hvis du refererer til en Microsoft-kompatibilitet navneområde, vi har PadRight til VB6's LSet (igen, helt anderledes end VB6's LSet, selvfølgelig) og PadLeft til RSet. (Der går de tre tastetryk, som vi har gemt med "+ ="!)

Og selvfølgelig, da vi er OOP nu, må du ikke bekymre dig om ejendomssæt, ejendomsudlejning og ejendomsret ikke er opfyldt i VB.NET, satser du!

Endelig debug. Udskriv bliver enten fejlfinding. Skriv eller fejlsøg. WriteLine. Kun nørder udskriver alt alligevel.

Dette berører ikke engang alle de NYE kommandoer i VB.NET, men vi er nødt til at stoppe denne vrøvl et eller andet sted.

I 4. plads, vi har Ændringer i procedureopkald!

Dette er prisen "godhed, renhed og sund dyd" og repræsenterer en masse hård kampagne af fraktionen "ikke mere slurvet kode".

I VB6, hvis en procedureparametervariabel er en iboende type, er det ByRef, medmindre du har kodet det ByVal eksplicit, men hvis det ikke er kodet ByRef eller ByVal, og det ikke er en iboende variabel, så er det ByVal... Forstået?

I VB.NET er det ByVal, medmindre det er kodet ByRef.

ByVal VB.NET-standard forhindrer forresten også ændringer i parametervariabler i procedurer fra at blive utilsigtet udbredt tilbage i opkaldskoden - en vigtig del af god OOP-programmering.

Microsoft "overbelaster" også VB.NET med en ændring i kravene til parenteser i procedureopkald.

I VB6 kræves parenteser omkring argumenter, når du foretager funktionsopkald, men ikke når du ringer til en subroutine, når du ikke bruger opkaldsangivelsen, men de er påkrævet, når opkaldsangivelsen bruges.

I VB.NET kræves parenteser altid omkring en ikke-fritagende argumentliste.

Bronzeprisen - 3. plads, går til Arrays er 0 baseret i stedet for 1 baserede!

Det er kun en syntaksændring, men denne ændring får status som "medaliepodium", fordi det vælges, "mest sandsynligt vil du skrue op din programlogik". Husk, 3. plads ER "Award (2)" på vores liste. Hvis du har tællere og matriser i dit VB6-program (og hvor mange der ikke gør det), MESSER DIG OP.

I ti år har folk spurgt, "Hvad ryger Microsoft, da de gjorde det på denne måde?" Og i ti år har programmerere slags universelt ignoreret det faktum, at der var et myArray (0) -element, der bare tog plads og ikke blev vant til hvad som helst... Bortset fra de programmerere, der brugte det og deres programmer så ud, mener jeg bare "underligt".

For I = 1 til 5
MyArray (I - 1) = Uanset hvad
Næste

Jeg mener, VIRKELIG! ...

Den sølvmedalje af 2. plads går til ære for en gammel ven, der blev smidt ned i programmets lille spand med VB6! Jeg taler om ingen anden end, Variantdatatype.

Sandsynligvis repræsenterer ingen andre funktioner i Visual Basic "notNet" bedre filosofien om "hurtig, billig og løs". Dette billede dog VB helt frem til introduktionen af ​​VB.NET. Jeg er gammel nok til at huske introduktionen af ​​Visual Basic 3.0 af Microsoft: "Oh Wow! Lookee her! Med den nye forbedrede Variant-datatype behøver du ikke at erklære variabler eller ikke noget. Du kan bare tænke dem op og kode dem. "

Microsoft ændrede deres melodi temmelig hurtigt på den ene og anbefalede at erklære variabler med en specifik datatype næsten øjeblikkeligt, hvilket lader mange af os undre os, "Hvis du ikke kan bruge varianter, hvorfor har du dem? "

Men mens vi handler om datatyper, skal jeg nævne, at en masse datatyper er ændret ud over at droppe Variant i våd cement. Der er en ny Char-datatype og en lang datatype, der er 64 bit. Decimal er måde anderledes. Kort og heltal er ikke samme længde længere.

Og der er en ny "Objekt" -datatype, der kan være hvad som helst. Hørte jeg nogen sige, "Son of Variant"?

Endelig! Guldmedaljen, 1. plads, den højeste pris, jeg kan tildele, går til ...

TA DAH!

VB.NET er endelig helt objektorienteret!

Når du nu går på stranden, sparker ikke C ++ -programmerne sand i dit ansigt og stjæler din (kæreste / kæreste - vælg en). Og det kan du stadig kode en komplet saldo for General Ledger Trial, mens de prøver at finde ud af, hvilke header-filer der skal inkluderes.

For første gang kan du kode så tæt på chippen, som du har brug for, og få adgang til alle de systeminterner, som dit hjerte ønsker uden at skulle ty til de grimme Win32 API-opkald. Du har arv, funktionsoverbelastning, asynkron multetrådning, affaldsopsamling og alt er et objekt. Kan livet blive bedre?

Hørte jeg nogen sige, at C ++ har flere arv, og .NET gør det stadig ikke?

Forbrænd ketteren!