Viis parimat muudatust VB 6-lt VB.NET-le

Visual Basic 1.0 oli kogu programmeerimise ajal suur maavärin. Enne VB1-d pidid Windowsi rakenduste loomiseks kasutama C, C ++ või mõnda muud jubedat arenduskeskkonda. Programmeerijad veetsid nädalaid sõna otseses mõttes lihtsalt aknaid ekraanidele valides, valides detailset ja raskesti siluvat koodi. (Sama, mida saate teha, lohistades vormi mõne sekundi jooksul tööriistaribalt.) VB1 oli tabamus ja gazillioonid programmeerijaid hakkasid seda kohe kasutama.

Kuid selleks, et võlukunsti juhtuda, tegi Microsoft mõned suured arhitektuurikompromissid. Kuna VB1 lõi vormid ja juhtelemendid, ei võimaldanud nad programmeerijal juurdepääsu koodile, mis seda tegi. Kas lasite VB-l kõike luua või kasutasite C ++.

VB 2 kuni 6 säilitasid sama arhitektuuri. Microsoft tegi mõned väga nutikad värskendused, mis andis programmeerijatele palju suurema kontrolli, kuid lõppkokkuvõttes ei suutnud programmeerijad siiski oma koodi VB-koodiga integreerida. See oli must kast - ja ka mitte heal juhul OOP. Teine viis seda öelda oli see, et programmeerijal polnud juurdepääsu sisemistele VB "objektidele", ja veel üks viis öelda, et VB6 polnud ikka veel täielikult "objektorienteeritud".

Vahepeal hakkasid ilmuma Java, Python ja terve rida muid programmeerimiskeeli, mis olid WERE objektorienteeritud. Visual Basic oli möödunud - suur aeg! See on olukord, mida Microsoft ei salli... ja nad otsustasid probleemi lõplikult lahendada. Lahenduseks on .NET.

Kuid selleks, et teha asju, mida NET pidi tegema, otsustas Microsoft, et nad peavad ühilduvuse katkestama. See tähendab, et Visual Basicu programmid olid (väga väikeste eranditega) ühilduvad "ülespoole" VB1-st kuni VB6-ni. Selles VB esimeses versioonis kirjutatud programm kompileerib ja töötab endiselt järgmises versioonis. Kuid koos VB.NET-iga leidis Microsoft, et nad lihtsalt ei suuda keelt täielikult OOP-i muuta ja säilitada ülespoole ühilduvuse.

Kui nad selle põhimõttelise otsuse vastu võtsid, avanesid kümne aasta jooksul akumuleerunud "sooviloendis" muudatused ja kõik need läksid uude VB.NET-i. Nagu Suurbritannias öeldakse: "Penniks, naelaks".

Ilma edasise viivituseta on siin minu väga isiklik nimekiri viiest peamisest muudatusest VB6-lt VB.NET-ile vastupidises järjekorras.

Wellllll... vaid veel üks viivitus. Kuna me oleme muutumas VB6-st, kus massiivi nimetatakse Dim myArray (5) on 6 elemente, neid on kuus. See sobib ainult ...

(Drum roll palun ...)

"Auhind (5)", meie 6. koht auhind antakse C-rühmade valikule: C-sarnased süntaksimuutused!

Nüüd saate a = a + 1 asemel koodiks + = 1 salvestada KOLM KÕIK KEYSTROKES!

Maailma programmeerijad, rõõmustage! VB on tõstetud C-tasemeni ja täiesti uus VB-d prooviv põlvkond jõuab pisut lähemale massilisele segadusse, mis seisavad silmitsi C ++ õpilastega.

Aga oota! Seal on veel!

VB.NET-l on nüüd "lühise loogika", mis on aastaid C ++ koodi viinud peeneid vigu, et säästa protsessori väärtuslikku nanosekundit. Lühise loogika hindab vajaduse korral loogilises avalduses ainult mitut tingimust. Näiteks:

Dim R Nagu tõeväärtus
R = funktsioon1 () ja funktsioon2 ()

VB6-s hinnatakse mõlemat funktsiooni, kas nad seda vajavad või mitte. Kui funktsioon VB.NET on funktsioon1 () vale, siis funktsiooni2 () eiratakse, kuna "R" ei saa olla tõene. Mis saab siis, kui globaalset muutujat funktsioonis Function2 () muudetakse - lihtsalt juhuslikult (C ++ programmeerijad ütleksid: " halb programmeerimine ".) Miks annab mu kood mõne aja jooksul vale tõlke, kui see on tõlgitud VB.NET? See võib olla see!

Sest Proovigeraskemaks, VB.NET teeb Saak natuke õnne ja Lõpuks saada tunnustust erakordse tõrkeotsingu eest

VB6-l oli viimane väljakutse GoTo: "On Error GoTo". Isegi pean tunnistama, et C ++ stiilis "Proovi-saak lõpuks" struktureeritud erandite käsitlemine on tohutu edasiminek, mitte ainult poole ulatuslik täiustus.

Mis te ütlete: "On Error GoTo" on endiselt VB.NET-is? Wellll... Püüame sellest mitte liiga palju rääkida.

5. koht valik on rühmaauhind: Mitmesugused käsud muutuvad! Nad peavad seda auhinda jagama ja neid on gazillionit. Microsoft on säästnud kümme aastat ja need lõikavad tõesti lahti.

VB.NET ei toeta enam funktsioone VarPtr, ObjPtr ja StrPtr, mis laadisid muutujate mäluaadressid. Ja see ei toeta VB6 LSeti, mida kasutati ühe kasutaja määratletud tüübi teisendamiseks teiseks. (Mitte segi ajada VB6 LSetiga, mis teeb midagi täiesti erinevat - vt allpool.)

Samuti pakume kiindumusi ad Letu, puudu, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar ja (minu isiklik lemmik!) GoSub.

Suhtlusring on muutunud GDI + DrawEllipse'i. Sama kehtib ka Line to DrawLine'i kohta. Arvestuses on meil nüüd Atni asemel Atan, Sign läheb sisse Sgniks ja Sqrt sobib suureks mänguks Sqr asemel.

Stringitöötluses, isegi kui need on Microsofti ühilduvuse kohta endiselt saadaval nimeruumi, meil on PadRight VB6 LSeti jaoks (jällegi täiesti erinev kui VB6 LSet, muidugi) ja PadLeft RSet jaoks. (Seal on kolm klahvivajutust, mille salvestasime klahviga "+ ="!)

Ja muidugi, kuna me tegutseme nüüd OOP-ga, ärge muretsege, kui varakomplekti, kinnisvara rentimist ja vara hankimist ei täideta VB.NET-is, panustate!

Lõpuks silumine. Prindist saab kas silumis. Kirjutage või siluge. WriteLine. Ainult nohikud prindivad kõik niikuinii.

See ei puuduta isegi kõiki VB.NET-i uusi käske, kuid peame selle jama kusagil lõpetama.

Sisse 4. koht, meil on Menetluskutsete muudatused!

See on auhind "headus, puhtus ja tervislik voorus" ning esindab fraktsiooni "pole enam lohakat koodi" palju kõvasti kampaaniat.

Kui protseduuri parameetri muutuja on sisemine tüüp, siis VB6 puhul on see ByRef, kui te pole seda kodeerinud ByVal sõnaselgelt, kuid kui see pole kodeeritud ByRef või ByVal ja see pole sisemine muutuja, siis on see ByVal... Sain aru?

VB.NET-is on see ByVal, välja arvatud juhul, kui see on kodeeritud ByRef.

Muide, ByVal VB.NET vaikeseade takistab ka protseduuride parameetrimuutujate muutmist tahtmatult tagasi kutsukoodiks - võtmeelemendiks hea OOP programmeerimisel.

Samuti "koormab Microsoft" VB.NETi, muutes protseduurikõnede sulgudele esitatavaid nõudeid.

VB6-s on funktsioonikõnede tegemisel argumentide ümber vaja esitada sulud, kuid mitte alamprogrammi kutsumisel, kui kõne väljavõtet ei kasutata, kuid need on vajalikud kõne väljavõtte kasutamisel.

VB.NET-is on sulgud vaja alati argumentide loendi ümber.

Pronksiauhind - 3. koht, läheb Massiivid põhinevad 0-l 1 asemel!

See on vaid üks süntaktiline muudatus, kuid see muudatus saab "medali poodiumile" staatuse, kuna see hääletatakse "tõenäoliselt oma programmi loogika kruvimiseks". Pidage meeles, et 3. koht ON "Auhind (2)" meie nimekirjas. Kui teie VB6-programmis on loendurid ja massiivid (ja kui palju neid pole), siis see SÕLMAB teid.

Juba kümme aastat on inimesed küsinud: "Mis suitsetas Microsoft, kui nad seda tegid?" Ja juba kümme aastat on programmeerijatel omamoodi ignoreeris tõsiasja, et seal oli element myArray (0), mis lihtsalt võttis ruumi ja ei harjunud midagi... Välja arvatud need programmeerijad, kes seda DID-d kasutavad ja nende programmid nägid välja, ma mõtlesin, et lihtsalt "imelikud".

I jaoks = 1 kuni 5
MyArray (I - 1) = mida iganes
Järgmine

Ma mõtlen, TEGELIKULT! ...

Aasta hõbemedal II koht läheb austama vana sõpra, kes oli VB6 möödumisega programmeerimise natuke ämbrisse visatud! Ma ei räägi kellestki teisest kui Variandmetüüp.

Tõenäoliselt ei esinda ükski Visual Basicu "notNet" üksikfunktsioon paremini filosoofiat "kiire, odav ja lõtv". See pilt näitas VB-d kuni VB.NET-i tutvustamiseni. Olen piisavalt vana, et meenutada Microsofti Visual Basic 3.0 tutvustamist: "Oh vau! Lookee siin! Uue, täiustatud variandi andmetüübi korral ei pea te muutujaid kuulutama ega midagi muud. Võite lihtsalt mõelda ja neid kodeerida. "

Microsoft muutis nende häälestust üsna kiiresti sellel ja soovitas muutujad deklareerida tähega konkreetne andmetüüp peaaegu kohe, jättes paljudel meist imestada: "Kui te ei saa variante kasutada, miks? kas neil on? "

Kuid kui me käsitleme andmetüüpe, peaksin mainima, et lisaks variandi tilgutamisele märjaks tsemendiks on muutunud ka paljud andmetüübid. Seal on uus Char andmetüüp ja Pikk andmetüüp, mis on 64 bitti. Komaosa on teistmoodi. Lühike ja täisarv pole enam ühepikkused.

Ja seal on uus "Objekti" andmetüüp, mis võib olla ükskõik mida. Kas ma kuulsin, et keegi ütles: "Variandi poeg"?

Lõpuks! Kuldmedal, 1. koht, kõrgeim autasu, mida võin anda, läheb ...

TA DAH!

VB.NET on lõpuks täielikult objektorienteeritud!

Nüüd, kui lähete randa, ei löö C ++ programmeerijad teie näole liiva ja varastavad teie (tüdruksõber / poiss-sõber - vali üks). Ja saate ka ikka kodeerige täielik pearaamatu prooviversioon, kui nad üritavad välja mõelda, millised päisefailid kaasata.

Esmakordselt saate kodeerida kiibile nii lähedal kui vaja ja pääseda juurde kõigile süsteemi sisemistele osadele, mida teie süda soovib ilma pidades silmas neid vastikuid Win32 API kõnesid. Teil on pärimine, funktsioonide ülekoormamine, asünkroonne mitmekeelsus, prügivedu ja kõik on objekt. Kas elu saab paremaks minna?

Kas ma kuulsin, et keegi ütles, et C ++-l on mitu pärimist ja .NET ikka veel mitte?

Põleta ketser!