Prvních pět změn z VB 6 na VB.NET

Visual Basic 1.0 byl během programování velkým zemětřesením. Před VB1 jste k vytváření aplikací Windows museli použít C, C ++ nebo nějaké jiné hrozné vývojové prostředí. Programátoři doslova strávili týdny jen kreslením oken na obrazovkách s vybíravým, podrobným, obtížně laditelným kódem. (To samé můžete udělat přetažením formuláře z panelu nástrojů během několika vteřin.) VB1 byl hitem a gaziliony programátorů jej okamžitě začaly používat.

Ale aby se magie stala, Microsoft udělal několik zásadních kompromisů v architektuře. Zejména, protože VB1 vytvořil formuláře a ovládací prvky, neumožnily programátorovi přístup k kódu, který to udělal. Buď necháte VB vytvořit vše, nebo jste použili C ++.

VB 2 až 6 udržovaly stejnou architekturu. Microsoft provedl některé velmi chytré aktualizace, které poskytly programátorům mnohem větší kontrolu, ale v konečné analýze programátoři stále nemohli integrovat svůj kód s kódem VB. Jednalo se o černou skříňku - a ne dobrým způsobem OOP. Dalším způsobem, jak to říci, bylo to, že programátor neměl přístup k interním „objektům“ VB a dalším způsobem, jak říkat, bylo to, že VB6 stále nebyl úplně „objektově orientovaný“.

Mezitím se začaly objevovat Java, Python a spousta dalších programovacích jazyků, které byly orientovány na objekt. Visual Basic byl předáván - velký čas! To je situace, kterou Microsoft netoleruje... a rozhodli se vyřešit problém jednou provždy. Řešením je .NET.

Microsoft však rozhodl, že musí „narušit kompatibilitu“, aby dělal věci, které potřebuje .NET. To znamená, že programy jazyka Visual Basic byly (s velmi malými výjimkami) „nahoru kompatibilní“ od VB1 až po VB6. Program napsaný v této první verzi VB by se stále kompiloval a spouštěl v další verzi. Ale s VB.NET, Microsoft zjistil, že prostě nemohli udělat jazyk úplně OOP a udržovat vzhůru kompatibilně.

Jakmile učinili toto zásadní rozhodnutí, protipovodňová vrata se otevřela na deset let nahromaděných změn „seznamu přání“ a VŠECHNY z nich šli do nového VB.NET. Jak říkají v Británii: „Za penny, za libru.“

Bez dalšího zpoždění zde je můj velmi osobní seznam pěti nejlepších změn z VB6 na VB.NET v opačném pořadí.

Dobře... jen další zpoždění. Protože přecházíme z VB6, kde je pole deklarováno jako Dim myArray (5) 6 prvků, máme jich šest. To jen zapadá ...

(Buben, prosím ...)

"Cena (5)", naše 6. místo cena je na výběr C groupies: Změny syntaxe typu C!

Nyní můžete místo a = a + 1 kódovat + = 1, čímž ušetříte TŘI CELÉ KLÁVESY!

Programátoři světa, radujte se! VB byla zvýšena na úroveň C a celá nová generace, která se snaží naučit VB, se trochu přiblíží masovému zmatku, kterému čelí studenti C ++.

Ale počkej! Je toho víc!

VB.NET nyní obsahuje „zkratovou logiku“, která roky zavedla do kódu C ++ jemné chyby, aby se ušetřily cenné nano sekundy času procesoru. Logika zkratu vyhodnocuje v logickém příkazu pouze více podmínek, pokud je to nutné. Například:

Dim R As Boolean
R = Function1 () a Function2 ()

Ve VB6 se vyhodnocují obě funkce, zda to potřebují nebo ne. U VB.NET, pokud Function1 () je false, Function2 () je ignorována, protože "R" nemůže být True. Ale co když se globální proměnná změní ve Function2 () - jen náhodou (programátoři C ++ by řekli: „by špatné programování “.) Proč můj kód vytváří špatnou odpověď někdy, když je přeložen VB.NET? To by mohlo být!

Pro Snaž seing. těžší, bude VB.NET Chytit trochu štěstí a Konečně získat uznání za "výjimečné" zpracování chyb.

VB6 měl poslední blokování GoTo: „On Error GoTo“. Dokonce musím přiznat, že strukturované zpracování výjimek ve stylu C ++ „Try-Catch-Nakonec“ je obrovské zlepšení, ne jen poloviční velké zlepšení.

Co říkáte, že „On Error GoTo“ je stále ve VB.NET? Dobře... Snažíme se o tom příliš nemluvit.

5. místo výběr je skupinové ocenění: Různé příkazy se mění! Musí se o tuto cenu dělit a je jich jeden gaz. Microsoft šetří již deset let a opravdu se uvolnil.

VB.NET již nepodporuje funkce VarPtr, ObjPtr a StrPtr, které získaly paměťovou adresu proměnných. A nepodporuje VB6 LSet, který byl použit k převodu jednoho typu definovaného uživatelem na jiný. (Nesmí se zaměňovat s VB6 LSet, který dělá něco úplně jiného - viz níže.)

Také nabízíme fond adieu, aby nechal, chybí, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar a (můj osobní oblíbený!) GoSub.

Kruh se proměnil v GDI + DrawEllipse. Totéž platí pro Line to DrawLine. Ve výpočtu nyní máme Atana místo Atna, Sign jde pro Sgn a Sqrt se hodí pro velkou hru namísto Sqr.

Při zpracování řetězců, i když jsou stále k dispozici, pokud odkazujete na kompatibilitu společnosti Microsoft Jmenný prostor, máme PadRight pro LSet VB6 (opět zcela jinak než LSet VB6) a PadLeft pro RSet. (Existují tři stisky kláves, které jsme uložili pomocí „+ =“!)

A samozřejmě, protože teď jsme OOP, nedělejte si starosti, pokud ve VB.NET není splněna sada vlastností, vlastnost pronajmout, a vlastnost získat, sázíte!

Nakonec Debug. Tisk se změní na Debug. Zápis nebo ladění. WriteLine. Jen blbci tisknout všechno stejně.

To se nedotkne ani všech NOVÝCH příkazů ve VB.NET, ale někde musíme tento nesmysl zastavit.

v 4. místo, my máme Změny volání procedur!

Toto je cena „dobroty, čistoty a zdravé ctnosti“ a představuje hodně tvrdých kampaní frakce „už žádný nedbalý kód“.

Pokud je ve VB6 proměnná parametru procedury vnitřní typ, pak je to ByRef, pokud jste ji nekódovali ByVal explicitně, ale pokud to není kódováno ByRef nebo ByVal a není to vnitřní proměnná, pak je to ByVal... Mám to?

Ve VB.NET je to ByVal, pokud není kódováno ByRef.

Výchozí nastavení ByVal VB.NET také zabraňuje neúmyslnému šíření změn proměnných parametrů v procedurách do volajícího kódu - klíčové součásti dobrého programování OOP.

Microsoft také „přetíží“ VB.NET změnou požadavků na závorky při volání procedur.

Ve VB6 jsou závorky kolem argumentů při volání funkcí, ale ne při volání podprogramu, když nepoužívají příkaz Call, ale jsou vyžadovány při použití příkazu Call.

Ve VB.NET jsou závorky vždy vyžadovány kolem seznamu neprázdných argumentů.

Bronzová cena - 3. místo, jde do Pole jsou založena na 0 namísto 1 na základě!

Je to jen jedna změna syntaxe, ale tato změna získá status „medaile stupně vítězů“, protože je volena, „s největší pravděpodobností zničí logiku programu“. Pamatujte, 3. místo JE „Cena (2)“ v našem seznamu. Pokud máte ve vašem VB6 programu čítače a pole (a kolik jich ne), bude vám tato MESS UP.

Již deset let se lidé ptají: „Co Microsoft kouřil, když to takto dělali?“ A deset let programátoři druh všeobecně ignoroval skutečnost, že existoval prvek myArray (0), který právě zabral prostor a nezvykl si na cokoliv... Kromě těch programátorů, kteří to DID používají a jejich programy vypadaly, myslím jen „divný“.

Pro I = 1 až 5
MyArray (I - 1) = Cokoli
další

Myslím, OPRAVDU! ...

Stříbrná medaile 2. místo jde na počest starého přítele, který byl vržen do bitové kbelíky programování s absolvováním VB6! Nemluvím o ničem jiném, než Datový typ varianty.

Pravděpodobně žádná další jediná funkce jazyka „notNet“ lépe nepředstavuje filozofii „rychlého, levného a uvolněného“. Tento obrázek pronikl VB až do zavedení VB.NET. Jsem dost starý na to, abych si vzpomněl na zavedení Visual Basic 3.0 od Microsoftu: „Oh Wow! Podívej se sem! U nového vylepšeného datového typu Variant nemusíte deklarovat proměnné ani nic. Můžete si jen myslet na ně a kódovat je. “

Microsoft změnil jejich melodii docela rychle na ten jeden a doporučil deklarovat proměnné s specifický datový typ téměř okamžitě a mnoho z nás se divilo: „Pokud nemůžete použít varianty, proč máte je? “

Ale zatímco jsme na téma datových typů, měl bych zmínit, že se mnoho datových typů změnilo kromě toho, že jsme Variantu rozložili na mokrý cement. Je zde nový datový typ Char a dlouhý datový typ, který je 64 bitů. Desetinné číslo je tak odlišné. Short a Integer již nejsou stejné délky.

A existuje nový datový typ „Object“, který může být cokoliv. Slyšel jsem, že někdo řekl: "Syn varianty"?

Konečně! Zlatá medaile, 1. místo, nejvyšší ocenění, které mohu udělit ...

TA DAH!

VB.NET je konečně zcela objektově orientovaný!

Nyní, když jdete na pláž, nebudou programátoři C ++ kopat do tváře písek a ukrást je (přítelkyně / přítel - vyberte si). A ty můžeš ještě pořád zakódujte kompletní zkušební zůstatek hlavní knihy, zatímco se snaží zjistit, které soubory záhlaví zahrnout.

Poprvé můžete kódovat co nejblíže čipu a získat přístup ke všem vnitřním systémovým funkcím, které vaše srdce touží bez museli uchýlit se k těm ošklivým hovorům Win32 API. Máte dědičnost, přetížení funkcí, asynchronní multithreading, sběr odpadu a všechno je objekt. Může se život zlepšit?

Slyšel jsem, že někdo říká, že C ++ má vícenásobné dědictví a .NET stále ne?

Spalte kacíře!