Az öt legfontosabb változás a VB 6-ról a VB.NET-re

A Visual Basic 1.0 jelentős földrengés volt a programozás során. A VB1 előtt C, C ++ vagy más szörnyű fejlesztési környezetet kellett használnia a Windows alkalmazások létrehozásához. A programozók szó szerint heteket töltöttek azzal, hogy válogatott, részletes, nehezen hibakereshető kódokkal rajzoltak ablakokat a képernyőkre. (Ugyanezt tehetjük, ha néhány másodperc alatt elhúzzuk az űrlapot az eszköztárról.) A VB1 találat volt, és a programozók gazililliói azonnal elkezdték használni.

De hogy a varázslat megtörténjen, a Microsoft komoly kompromisszumokat tett az építészetben. Különösen, mivel a VB1 létrehozta az űrlapokat és a vezérlőket, nem engedték meg a programozók számára, hogy hozzáférjenek a létrehozott kódhoz. Vagy hagyta, hogy a VB mindent készítsen, vagy a C ++ -ot használja.

A VB 2–6 ugyanazt az architektúrát tartotta fenn. A Microsoft végrehajtott néhány nagyon okos frissítést, amely sokkal nagyobb ellenőrzést adott a programozóknak, ám a végső elemzés során a programozók még mindig nem tudták integrálni kódjukat a VB-kóddal. Fekete doboz volt - és a jó OOP szempontjából sem. Egy másik módja ennek mondására az volt, hogy a programozónak nem volt hozzáférése a belső VB "objektumokhoz", és egy másik módja annak kijelentésére, hogy a VB6 még mindig nem volt teljesen "objektumorientált".

Időközben a Java, a Python és a sok más programozási nyelv, amelyek WERE objektumorientáltak voltak, megjelentek. A Visual Basic egyre inkább átesett - nagy idő! Ezt a helyzetet a Microsoft nem tolerálja... és úgy döntöttek, hogy egyszer és mindenkorra megoldják a problémát. A megoldás a .NET.

De a .NET-hez szükséges dolgok elvégzéséhez a Microsoft úgy döntött, hogy "meg kell szakítaniuk a kompatibilitást". Vagyis a Visual Basic programok (nagyon kis kivételekkel) "felfelé kompatibilisek" voltak a VB1-től egészen a VB6-ig. A VB első verziójában írt program továbbra is összeállítja és futtatja a következő verzióban. A VB.NET-rel azonban a Microsoft úgy találta, hogy nem tudják teljesen elkészíteni a nyelvet, és fenntartják a felfelé való kompatibilitást.

Miután meghozták ezt az alapvető döntést, az árvízkapu nyitotta meg a tíz évig felhalmozódott "kívánságlista" változásait, és mindegyik bekerült az új VB.NET-be. Mint mondják Nagy-Britanniában: "Egy centért, egy fontért".

További késedelem nélkül itt van a nagyon személyes listám az öt legfontosabb változásról a VB6-ról a VB.NET-re fordított sorrendben.

Wellllll... csak egy további késés. Mivel a VB6-tól váltunk, ahol egy tömböt Dim myArray-ként deklaráltak (5) van 6 elemek, hat közülük van. Csak illeszkedő ...

(Dob tekercs kérem ...)

"Díj (5)", mi 6. hely a díjat a C csoportos választás kapja: C-szerű szintaxis változások!

Most a + = 1 helyett kódolhatja a = a + 1 helyett, HÁROM HATÁRANYAGOT mentve!

A világ programozói, örülj! A VB-t a C szintre emelték, és egy teljesen új generáció, aki megpróbálja megtanulni a VB-t, kissé közelebb kerül a tömeges zavarhoz, amely a C ++ hallgatóival szembesül.

De várj! Van még!

A VB.NET most a "rövidzár logika" funkcióval rendelkezik, amely évek óta finom hibákat vezetett be a C ++ kódba, hogy megtakarítsa a processzor értékes értékes másodperceit. A rövidzárlogika csak több feltételt értékel logikai utasításban, ha szükséges. Például:

Dim R Mint logikai
R = Funkció1 () és Funkció2 ()

A VB6-ban mindkét funkció ki van értékelve, szükségük van rá vagy sem. A VB.NET esetén, ha a Function1 () hamis, akkor a Function2 () figyelmen kívül hagyásra kerül, mivel az "R" nem lehet igaz. De mi van, ha egy globális változó megváltozik a Function2 () -ben - csak véletlenszerűen (a C ++ programozók azt mondanák: " rossz programozás ".) Miért ad a kódom gyakran hibás választ, amikor erre fordítják VB.NET? Lehet, hogy ez!

mert Próbáld kiegyre nehezebbé válik a VB.NET Fogás egy kis szerencsét és Végül szerezzen elismerést a "kivételes" hibakezelésért.

A VB6-nál volt az utolsó tartós GoTo: "On Error GoTo". Még azt is be kell vallanom, hogy a C ++ stílusú, "Try-Catch-Végül" strukturált kivételkezelés hatalmas fejlesztés, nem csupán fél hatalmas fejlesztés.

Mi van, ha azt mondod, "On Error GoTo" még mindig megtalálható a VB.NET-ben? Wellll... Igyekszünk, hogy ne beszéljünk erről túl sokat.

5. hely A kiválasztás csoportdíj: A Vegyes Parancs változások! Meg kell osztaniuk ezt a díjat, és ott van egy milliárd számuk. A Microsoft tíz éve takarít meg, és tényleg meglazult.

A VB.NET már nem támogatja a VarPtr, ObjPtr és StrPtr funkciókat, amelyek lekérdezték a változók memóriacímét. És nem támogatja a VB6 LSet-et, amelyet az egyik felhasználó által definiált típus konvertálására használtak. (Nem szabad összetéveszteni a VB6 LSet-tel, amely valami teljesen mást csinál - lásd alább.)

Arra is kedvelt ajánlatot adunk, hogy Let, Hiányzik, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar és (az én személyes kedvencem!) GoSub.

A kör átalakult a GDI + DrawEllipse fájlba. Ugyanez vonatkozik a Line to DrawLine-re. Számítások szerint Atn helyett Atant használunk, Sign beírja az Sgn értéket, és az Sqrt megfelel a nagy játékhoz Sqr helyett.

A karakterlánc-feldolgozás során, bár ezek továbbra is elérhetők, ha hivatkozik egy Microsoft kompatibilitásra névtér, van PadRight a VB6 LSethez (ismét teljesen különbözik a VB6 LSetétől, természetesen) és a PadLefthez az RSet számára. (Itt van a három billentyűleütés, amelyet a "+ =" -val mentettünk!)

És természetesen, mivel most OOP vagyunk, ne aggódjon, ha a Property Set, az Property Let és a Property Get nem teljesül a VB.NET-en, akkor fogadsz!

Végül, hibakeresés. A nyomtatás vagy Hibakeresés lesz. Írjon vagy hibakeresést. WriteLine nevû. Csak a majmok kinyomtatnak mindent.

Ez nem érinti a VB.NET összes ÚJ parancsát, de valahol meg kell állítanunk ezt az ostobaságot.

Ban ben 4. hely, nekünk van Az eljáráshívások megváltoztatása!

Ez a "jóság, tisztaság és egészséges erény" díj, és a "nincs több hanyagkód" frakció sok kemény kampányát képviseli.

A VB6-ban, ha egy eljárásparaméter-változó egy belső típus, akkor ez ByRef, hacsak nem kódolta A ByVal kifejezetten, de ha nem a ByRef vagy a ByVal kódolja, és nem egy belső változó, akkor az ByVal... Megvan?

A VB.NET-ben ez a ByVal, kivéve, ha a ByRef kódolja.

A ByVal VB.NET alapértelmezés szerint egyébként megakadályozza, hogy az eljárások paraméterváltozóiban bekövetkező változások véletlenül visszakerüljenek a hívó kódba - ez a jó OOP programozás kulcseleme.

A Microsoft emellett "túlterheli" a VB.NET-et, megváltoztatva az eljáráshívások zárójelére vonatkozó követelményeket.

A VB6-ban zárójelek szükségesek az argumentumok körül funkcionális hívások kezdeményezésekor, de nem egy alprogram hívásakor, ha nem használja a Hívási nyilatkozatot, de ezek szükségesek a Hívási nyilatkozat használatakor.

A VB.NET-ben zárójelekre van szükség mindig a nem üres argumentumlista körül.

Bronz-díj - 3. hely, megy A tömbök 0-n alapulnak, 1-nél nem!

Ez csak egy szintaxisváltozás, de ez a változás „érme dobogóra” státuszt kap, mert szavazásra kerül, „valószínűleg csavarja be a program logikáját”. Ne feledje, a 3. hely IS "Díj (2)" a listánkon. Ha számlálók és tömbök vannak a VB6 programjában (és hány nem rendelkezik), akkor ezt fel fogja mondani.

Tíz éve az emberek azt kérdezik: "Mit dohányzott a Microsoft, amikor így csinálták?" És tíz évig a programozók rendelkeznek valahogy általánosan figyelmen kívül hagyta azt a tényt, hogy volt egy myArray (0) elem, amely csak helyet foglalott el és nem szokott hozzá bármi... Azon programozók kivételével, akik DID-t használtak, és a programjuk, úgy értem, csak "furcsa".

I = 1-5
MyArray (I - 1) = Bármi
Következő

Értem, IGAZÁN! ...

Ausztrál ezüstérme 2. hely tiszteli egy régi barátot, akit a VB6 átadásával a programozás kis vödörébe dobtak! Nem másról beszélek, mint A variáns adattípus.

Valószínűleg a Visual Basic "notNet" egyetlen különlegessége nem képviseli jobban a "gyors, olcsó és laza" filozófiát. Ez a kép a VB-t vezérelte egészen a VB.NET bevezetéséig. Elég idős vagyok ahhoz, hogy emlékezzem a Visual Basic 3.0 Microsoft bevezetésére: "Oh Wow! Lookee itt! Az új, továbbfejlesztett Variant adattípussal nem kell változókat deklarálnia, vagy nem. Gondolhatja őket, és kódolhatja őket. "

A Microsoft nagyon gyorsan megváltoztatta dallamukat ezen a téren, és javasolta a változó bejelentését a a specifikus adattípust szinte azonnal, így sokan kíváncsi lehetünk: "Ha nem tudod használni a változatokat, miért megvan? "

De amíg az adattípusok kérdésével foglalkozunk, meg kell említenem, hogy sok variáció megváltozott amellett, hogy a Variantot nedves cementbe engedte. Van egy új Char adattípus és egy hosszú adattípus, amely 64 bit. A tizedes egészen más. A rövid és az egész már nem azonos hosszúságú.

És létezik egy új "Object" adattípus is bármi. Hallottam, hogy valaki azt mondta: "Variant fia"?

Végül! Az aranyérmet, 1. hely, a legmagasabb díjat, amit adok, megkapom ...

TA DAH!

A VB.NET végül teljesen objektumorientált!

Most, amikor elmész a tengerpartra, a C ++ programozók nem rúgnak homokba az arcodban, és ellopják az ön barátnőjét / barátját - válassz egyet). És te tudod még mindig kódolja a teljes főkönyvi próba-egyensúlyt, miközben megpróbálják kitalálni, hogy mely fejléc fájlokat tartalmazzák.

Ez az első alkalom, hogy a lehető legközelebb esik a kódhoz, és hozzáférhessen minden olyan belső rendszerhez, amelyet szíve kíván nélkül kellett igénybe venni ezeket a csúnya Win32 API hívásokat. Öröklődése, funkció túlterhelése, aszinkron többszálú menete, szemetes gyűjtése és minden egy tárgy. Jobb lesz az élet?

Hallottam, hogy valaki azt mondta, hogy a C ++ többszörös örökséggel rendelkezik, és a .NET továbbra sem?

Égj az eretneket!