De top vijf verandert van VB 6 naar VB.NET

Visual Basic 1.0 was een grote aardbeving tijdens het programmeren. Vóór VB1 moest je C, C ++ of een andere vreselijke ontwikkelomgeving gebruiken om Windows-applicaties te maken. Programmeurs brachten letterlijk weken door met het tekenen van vensters op schermen met kieskeurige, gedetailleerde, moeilijk te debuggen code. (Hetzelfde wat je kunt doen door binnen een paar seconden een formulier van de werkbalk te slepen.) VB1 was een hit en talloze programmeurs begonnen het meteen te gebruiken.

Maar om de magie te laten gebeuren, heeft Microsoft een aantal belangrijke architectuurcompromissen gesloten. Omdat VB1 de formulieren en besturingselementen heeft gemaakt, hebben ze de programmeur met name geen toegang verleend tot de code die het heeft gedaan. Je hebt VB alles laten maken of je hebt C ​​++ gebruikt.

VB 2 tot en met 6 behielden dezelfde architectuur. Microsoft heeft een aantal zeer slimme updates gemaakt die programmeurs veel meer controle gaven, maar in de uiteindelijke analyse konden programmeurs hun code nog steeds niet integreren met de VB-code. Het was een zwarte doos - en ook niet op de goede OOP-manier. Een andere manier om dit te zeggen was dat de programmeur geen toegang had tot de interne VB "objecten" en een andere manier om te zeggen dat VB6 nog steeds niet volledig "objectgericht" was.

Ondertussen verschenen Java, Python en een heleboel andere programmeertalen die WERE-objectgericht waren. Visual Basic werd gepasseerd - groots! Dit is een situatie die Microsoft niet tolereert... en ze besloten het probleem voor eens en voor altijd op te lossen. De oplossing is .NET.

Maar om de dingen te doen die .NET moest doen, besloot Microsoft dat ze de compatibiliteit moesten verbreken. Dat wil zeggen, Visual Basic-programma's waren (op enkele zeer kleine uitzonderingen na) "opwaarts compatibel" van VB1 tot en met VB6. Een programma dat in die eerste versie van VB is geschreven, zou nog steeds worden gecompileerd en in de volgende versie worden uitgevoerd. Maar met VB.NET ontdekte Microsoft dat ze de taal gewoon niet volledig OOP konden maken en compatibel konden houden.

Toen ze eenmaal deze fundamentele beslissing hadden genomen, gingen de sluisdeuren open na tien jaar van opeenvolgende "wensenlijst" -wijzigingen en ze gingen allemaal naar het nieuwe VB.NET. Zoals ze in Groot-Brittannië zeggen: "In voor een cent, voor een pond."

Zonder verdere vertraging, hier is mijn zeer persoonlijke lijst van de top vijf veranderingen van VB6 naar VB.NET in omgekeerde volgorde.

Wellllll... nog een vertraging. Omdat we overstappen van VB6, waar een array is gedeclareerd als Dim myArray (5) heeft 6 elementen, we hebben er zes. Het past alleen ...

(Tromgeroffel aub ...)

"Award (5)", onze 6e plaats prijs gaat naar de keuze van de C groupies: C-achtige syntaxisveranderingen!

Nu kunt u a + = 1 coderen in plaats van a = a + 1, waardoor DRIE HELE TOETSEN worden bespaard!

Programmeurs van de wereld, verheug u! VB is verhoogd naar C-niveau en een hele nieuwe generatie die VB probeert te leren, zal een beetje dichterbij de massale verwarring komen waarmee studenten van C ++ worden geconfronteerd.

Maar wacht! Er is meer!

VB.NET beschikt nu over "kortsluitlogica" die jarenlang subtiele bugs in C ++ - code heeft geïntroduceerd om kostbare nano-seconden processortijd te besparen. Kortsluitlogica evalueert indien nodig alleen meerdere voorwaarden in een logische verklaring. Bijvoorbeeld:

Dim R als Boolean
R = Function1 () en Function2 ()

In VB6 worden beide functies geëvalueerd of ze het nodig hebben of niet. Met VB.NET, als Function1 () false is, wordt Function2 () genegeerd omdat "R" niet True kan zijn. Maar wat als een globale variabele wordt gewijzigd in Function2 () - toevallig (C ++ programmeurs zouden zeggen, "door slechte programmering ".) Waarom geeft mijn code soms het verkeerde antwoord wanneer het wordt vertaald naar VB.NET? Dit zou het kunnen zijn!

Voor ProberenAls het moeilijker is, zal VB.NET dat doen Vangst een beetje geluk en Tenslotte erkend worden voor "uitzonderlijke" foutafhandeling.

VB6 had de laatste holdout GoTo: "On Error GoTo". Zelfs ik moet toegeven dat de gestructureerde uitzonderingsbehandeling in C ++ -stijl "Try-Catch-Eindelijk" een enorme verbetering is, niet alleen een half enorme verbetering.

Wat, zeg je "On Error GoTo" staat nog steeds in VB.NET? Wellll... Daar proberen we niet te veel over te praten.

5e plaats selectie is een groepsprijs: De diverse opdrachtwijzigingen! Ze moeten deze prijs delen en er zijn er een ontelbaar aantal. Microsoft heeft tien jaar gespaard en ze zijn echt losgekomen.

VB.NET ondersteunt niet langer VarPtr-, ObjPtr- en StrPtr-functies die het geheugenadres van variabelen hebben opgehaald. En het ondersteunt geen VB6 LSet die werd gebruikt om het ene door de gebruiker gedefinieerde type naar het andere te converteren. (Niet te verwarren met VB6 LSet die iets heel anders doet - zie hieronder.)

We bieden ook dol op Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar en (mijn persoonlijke favoriet!) GoSub.

Circle is veranderd in GDI + DrawEllipse. Hetzelfde geldt voor Line to DrawLine. In de berekening hebben we nu Atan in plaats van Atn, Sign gaat in voor Sgn en Sqrt past in het grote spel in plaats van Sqr.

Bij stringverwerking, ook al zijn ze nog steeds beschikbaar als u verwijst naar een Microsoft-compatibiliteit naamruimte, we hebben PadRight voor VB6's LSet (nogmaals, totaal anders dan VB6's LSet natuurlijk) en PadLeft voor RSet. (Daar komen de drie toetsaanslagen die we hebben opgeslagen met "+ ="!)

En natuurlijk, aangezien we nu OOP zijn, maak je geen zorgen als Property Set, Property Let en Property Get niet worden gehaald in VB.NET, je wedt!

Eindelijk Debug. Afdrukken wordt ofwel Debug. Schrijven of debuggen. Schrijf lijn. Alleen nerds drukken sowieso alles af.

Dit raakt niet eens alle NIEUWE commando's in VB.NET, maar we moeten deze onzin ergens stoppen.

In 4e plaats, wij hebben Wijzigingen in procedure-oproepen!

Dit is de onderscheiding "goedheid, zuiverheid en gezonde deugd" en vertegenwoordigt veel harde campagnes door de factie "niet meer slordige code".

Als in VB6 een procedureparameter variabele een intrinsiek type is, dan is het ByRef, tenzij je het hebt gecodeerd ByVal expliciet, maar als het niet gecodeerd is door ByRef of ByVal en het is geen intrinsieke variabele, dan is het ByVal... Heb het?

In VB.NET is het ByVal, tenzij het ByRef is gecodeerd.

De ByVal VB.NET-standaard voorkomt trouwens ook dat wijzigingen in parametervariabelen in procedures niet onbedoeld worden teruggeplaatst in de aanroepende code - een belangrijk onderdeel van goede OOP-programmering.

Microsoft "overlaadt" VB.NET ook met een wijziging in de vereisten voor haakjes in procedureaanroepen.

In VB6 zijn haakjes vereist rond argumenten bij het maken van functieaanroepen, maar niet bij het aanroepen van een subroutine wanneer de Call-instructie niet wordt gebruikt, maar ze zijn vereist wanneer de Call-instructie wordt gebruikt.

In VB.NET zijn haakjes altijd vereist rond een lijst met niet-lege argumenten.

The Bronze Award - 3de plaats, gaat naar Arrays zijn gebaseerd op 0 in plaats van op 1!

Het is slechts één wijziging in de syntaxis, maar deze wijziging krijgt de status "medaillepodium" omdat er wordt gestemd, "hoogstwaarschijnlijk om uw programmalogica te verknoeien". Onthoud, 3e plaats IS "Award (2)" in onze lijst. Als je tellers en arrays in je VB6-programma hebt (en hoeveel niet), dan zal deze MESS YOU UP.

Tien jaar lang hebben mensen gevraagd: 'Wat rookte Microsoft toen ze het op deze manier deden?' En programmeurs hebben dat al tien jaar min of meer universeel genegeerd het feit dat er een myArray (0) -element was dat gewoon ruimte in beslag nam en niet werd gebruikt voor iets... Behalve die programmeurs die het gebruikten en hun programma's er uitzagen, bedoel ik gewoon "raar".

Voor I = 1 tot 5
MyArray (I - 1) = wat dan ook
De volgende

Ik bedoel, WERKELIJK! ...

De zilveren medaille van 2de plaats is ter ere van een oude vriend die met het overlijden van VB6 in de kleine emmer programmeren is gevallen! Ik spreek van niemand minder dan, Het Variant Datatype.

Waarschijnlijk vertegenwoordigt geen enkel ander kenmerk van Visual Basic "notNet" beter de filosofie van "snel, goedkoop en los". Deze afbeelding bleef VB volgen tot aan de introductie van VB.NET. Ik ben oud genoeg om de introductie van Visual Basic 3.0 door Microsoft te herinneren: "Oh wauw! Kijk eens hier! Met het nieuwe, verbeterde gegevenstype Variant hoeft u geen variabelen te declareren of niets. Je kunt ze gewoon bedenken en ze coderen. '

Microsoft veranderde hun tune vrij snel op die ene en adviseerde variabelen te declareren met een specifieke datatype bijna onmiddellijk, waardoor velen van ons zich afvragen: "Als u geen varianten kunt gebruiken, waarom dan ze hebben?"

Maar terwijl we het over datatypes hebben, moet ik vermelden dat veel datatypes zijn veranderd naast het laten vallen van Variant in nat cement. Er is een nieuw Char-datatype en een lang datatype van 64 bits. Decimaal is heel anders. Short en Integer zijn niet meer even lang.

En er is een nieuw datatype "Object" dat kan zijn iets. Hoorde ik iemand zeggen: "Zoon van Variant"?

Tenslotte! De gouden medaille, 1e plaats, de hoogste onderscheiding die ik kan geven gaat naar ...

TA DAH!

VB.NET is eindelijk volledig objectgericht!

Als je nu naar het strand gaat, zullen de C ++ -programmeurs geen zand in je gezicht trappen en je (vriendin / vriend - kies er een) stelen. En jij kan nog steeds codeer een volledige grootboekproefbalans terwijl ze proberen te achterhalen welke headerbestanden ze moeten opnemen.

Voor het eerst kunt u zo dicht bij de chip coderen als u nodig heeft en heeft u toegang tot alle systeeminternals die uw hartje begeert zonder moeten toevlucht nemen tot die vervelende Win32 API-aanroepen. Je hebt overerving, overbelasting van functies, asynchrone multithreading, garbage collection en alles is een object. Kan het leven beter worden?

Heb ik iemand horen zeggen dat C ++ meerdere overervingen heeft en .NET nog steeds niet?

Verbrand de ketter!