Pięć najlepszych zmian z VB 6 na VB.NET

Visual Basic 1.0 był poważnym trzęsieniem ziemi podczas programowania. Przed wersją VB1 trzeba było używać C, C ++ lub innego okropnego środowiska programistycznego do tworzenia aplikacji Windows. Programiści dosłownie spędzili tygodnie po prostu rysując okna na ekranach z wybierającym, szczegółowym, trudnym do debugowania kodem. (To samo, co możesz zrobić, przeciągając formularz z paska narzędzi w kilka sekund.) VB1 był hitem i od razu zaczęły go używać miliardy programistów.

Aby jednak magia się wydarzyła, Microsoft dokonał poważnych kompromisów w architekturze. W szczególności, ponieważ VB1 utworzył formularze i kontrolki, nie zezwalał programiście na dostęp do kodu, który to zrobił. Możesz albo VB stworzyć wszystko, albo użyłeś C ++.

Wersje od VB 2 do 6 utrzymywały tę samą architekturę. Microsoft dokonał bardzo sprytnych aktualizacji, które dały programistom znacznie większą kontrolę, ale w końcowej analizie programiści nadal nie mogli zintegrować swojego kodu z kodem VB. To była czarna skrzynka - i też nie w dobrym stylu OOP. Innym sposobem powiedzenia tego było to, że programista nie miał dostępu do wewnętrznych „obiektów” VB, a innym sposobem powiedzenia, że ​​VB6 wciąż nie był w pełni „zorientowany obiektowo”.

W międzyczasie zaczęły pojawiać się Java, Python i wiele innych języków programowania, które WERE zorientowane obiektowo. Visual Basic już dawno mijał - wielki czas! Jest to sytuacja, w której Microsoft nie toleruje... i postanowili rozwiązać problem raz na zawsze. Rozwiązaniem jest .NET.

Aby jednak zrobić to, co musiał .NET, Microsoft zdecydował, że musi „zerwać kompatybilność”. Oznacza to, że programy Visual Basic były (z bardzo małymi wyjątkami) „kompatybilne w górę” od VB1 aż do VB6. Program napisany w tej pierwszej wersji VB nadal się kompiluje i uruchamia w następnej wersji. Ale dzięki VB.NET Microsoft stwierdził, że po prostu nie mogli sprawić, by język był całkowicie OOP i utrzymywał kompatybilność w górę.

Kiedy podjęli tę fundamentalną decyzję, bramy przeciwpowodziowe otworzyły się po dziesięciu latach skumulowanych zmian „listy życzeń” i WSZYSTKIE z nich weszły w nową VB.NET. Jak mówią w Wielkiej Brytanii: „Za grosza, za funta”.

Bez dalszej zwłoki oto moja bardzo osobista lista pięciu najlepszych zmian z VB6 na VB.NET w odwrotnej kolejności.

Wellllll... jeszcze jedno opóźnienie. Ponieważ zmieniamy z VB6, gdzie tablica zadeklarowana jako Dim myArray (5) ma 6 elementy, mamy ich sześć. Pasuje tylko ...

(Proszę o werble ...)

„Award (5)”, nasza 6. miejsce nagroda trafia do wyboru grupy C: C-podobne zmiany składniowe!

Teraz możesz napisać kod a + = 1 zamiast a = a + 1, oszczędzając TRZY CAŁE KLUCZE!

Programiści świata, Radujcie się! VB zostało podniesione do poziomu C, a cała nowa generacja próbująca nauczyć się VB zbliży się nieco do masowego zamieszania, które napotyka studentów C ++.

Ale poczekaj! Jest więcej!

VB.NET posiada teraz „logikę zwarć”, która od lat wprowadza subtelne błędy w kodzie C ++, aby zaoszczędzić cenne nanosekundy czasu procesora. Logika zwarć ocenia tylko kilka warunków w instrukcji logicznej, jeśli to konieczne. Na przykład:

Dim R As Boolean
R = funkcja 1 () i funkcja 2 ()

W VB6 obie funkcje są oceniane, czy tego potrzebują, czy nie. W VB.NET, jeśli funkcja 1 () ma wartość false, funkcja 2 () jest ignorowana, ponieważ „R” nie może być prawdziwe. Ale co jeśli zmienna globalna zostanie zmieniona w Function2 () - przypadkiem (programiści C ++ powiedzieliby „przez słabe programowanie ”.) Dlaczego mój kod generuje złą odpowiedź przez pewien czas, kiedy jest tłumaczony VB.NET? To może być to!

Dla Próbowaćtrudniej VB.NET będzie Złapać trochę szczęścia i Wreszcie zostać rozpoznanym za „wyjątkową” obsługę błędów.

VB6 miał ostatnią blokadę GoTo: „On Error GoTo”. Nawet muszę przyznać, że ustrukturyzowana obsługa wyjątków w stylu C ++ „Try-Catch-Wreszcie” to ogromna poprawa, a nie tylko połowa ogromnej poprawy.

Co powiesz: „On Error GoTo” jest nadal w VB.NET? Wellll... Staramy się nie rozmawiać o tym za dużo.

5 miejsce wybór jest nagrodą grupową: Różne polecenia zmieniają się! Muszą podzielić się tą nagrodą i jest ich miliard. Microsoft oszczędza od dziesięciu lat i naprawdę się uwolnili.

VB.NET nie obsługuje już funkcji VarPtr, ObjPtr i StrPtr, które pobrały adres pamięci zmiennych. I nie obsługuje VB6 LSet, który został użyty do konwersji jednego typu zdefiniowanego przez użytkownika na inny. (Nie mylić z VB6 LSet, który robi coś zupełnie innego - patrz poniżej.)

Licytujemy również zaadresowane do Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar i (mój osobisty faworyt!) GoSub.

Circle przekształcił się w GDI + DrawEllipse. To samo dotyczy linii do rysowania linii. W obliczeniach mamy teraz Atan zamiast Atn, Sign idzie po Sgn, a Sqrt pasuje do wielkiej gry zamiast Sqr.

Podczas przetwarzania ciągów, nawet jeśli są one nadal dostępne, jeśli odwołujesz się do zgodności Microsoft przestrzeń nazw, mamy PadRight dla LSet VB6 (znowu, zupełnie inny niż LSet VB6, oczywiście) i PadLeft dla RSet. (Istnieją trzy naciśnięcia klawiszy, które zapisaliśmy za pomocą „+ =”!)

I oczywiście, ponieważ jesteśmy teraz w trybie OOP, nie martw się, jeśli w VB.NET nie zostanie spełniony zestaw nieruchomości, wynajem nieruchomości i uzyskanie nieruchomości.

Wreszcie debuguj. Drukuj staje się albo debugowaniem. Napisz lub debuguj. WriteLine. Zresztą tylko kujony drukują wszystko.

To nawet nie dotyka wszystkich NOWYCH poleceń w VB.NET, ale musimy gdzieś zatrzymać ten nonsens.

W 4 miejsce, mamy Zmiany w wywołaniach procedur!

Jest to nagroda „dobroć, czystość i zdrowa cnota” i reprezentuje wiele trudnych kampanii prowadzonych przez frakcję „nigdy więcej niechlujnego kodu”.

W VB6, jeśli zmienna parametru procedury jest typem wewnętrznym, to jest ByRef, chyba że ją zakodowałeś ByVal wyraźnie, ale jeśli nie jest zakodowany ByRef lub ByVal i nie jest to zmienna wewnętrzna, to jest ByVal... Zrozumiałeś?

W VB.NET jest to ByVal, chyba że jest kodowane ByRef.

Nawiasem mówiąc, domyślna wartość ByVal VB.NET zapobiega również przypadkowemu propagowaniu zmian zmiennych parametrów w procedurach do kodu wywołującego - kluczowego elementu dobrego programowania OOP.

Microsoft „przeciąża” VB.NET ze zmianą wymagań dotyczących nawiasów w wywołaniach procedur.

W VB6 nawiasy są wymagane wokół argumentów podczas wywoływania funkcji, ale nie podczas wywoływania podprogramu, gdy nie używa się instrukcji Call, ale są one wymagane, gdy używana jest instrukcja Call.

W VB.NET nawiasy są zawsze wymagane wokół niepustej listy argumentów.

Brązowa nagroda - 3 miejsce, idzie do Tablice są oparte na 0 zamiast na 1!

To tylko jedna zmiana składni, ale ta zmiana otrzymuje status „podium medalowego”, ponieważ zostanie uznana za „najprawdopodobniej zepsuć logikę programu”. Pamiętaj, 3 miejsce JEST „Award (2)” na naszej liście. Jeśli masz liczniki i tablice w swoim programie VB6 (a ilu ich nie ma), ten MESS YOU UP.

Od dziesięciu lat ludzie pytają: „Co Microsoft palił, kiedy robili to w ten sposób?” I przez dziesięć lat programiści tak w pewnym sensie zignorował fakt, że istniał element myArray (0), który po prostu zajmował miejsce i nie był przyzwyczajony do byle co... Z wyjątkiem tych programistów, którzy tego używali, a ich programy wyglądały na „dziwne”.

Dla I = 1 do 5
MyArray (I - 1) = Cokolwiek
Kolejny

Mam na myśli, NAPRAWDĘ! ...

Srebrny Medal 2. miejsce idzie na cześć starego przyjaciela, który został upuszczony do segmentu programowania wraz z przejściem VB6! Nie mówię o niczym innym, jak Wariant typu danych.

Prawdopodobnie żadna inna cecha Visual Basic „notNet” lepiej nie odzwierciedla filozofii „szybkiego, taniego i luźnego”. Ten obraz utrzymywał VB aż do wprowadzenia VB.NET. Jestem na tyle stary, że pamiętam wprowadzenie Visual Basic 3.0 firmy Microsoft: „Och, łał! Spójrz tutaj! Dzięki nowemu, ulepszonemu typowi danych Variant nie musisz deklarować zmiennych ani niczego. Możesz po prostu wymyślić je i zakodować.

Microsoft dość szybko zmienił melodię i zalecił zadeklarowanie zmiennych za pomocą konkretny typ danych niemal natychmiast, pozostawiając wielu z nas zastanawiających się: „Jeśli nie możesz użyć Wariantów, dlaczego mieć ich?"

Ale skoro jesteśmy na temat typów danych, powinienem wspomnieć, że wiele rodzajów danych zmieniło się oprócz upuszczania Varianta na mokry cement. Dostępny jest nowy typ danych Char i długi typ danych, który ma 64 bity. Dziesiętny jest inny. Short i Integer nie są już tej samej długości.

Istnieje także nowy typ danych „Object” byle co. Czy słyszałem, jak ktoś powiedział:Syn wariantu"?

Wreszcie! Złoty Medal, 1. miejsce, najwyższa nagroda, jaką mogę przyznać, to ...

TA DAH!

VB.NET jest w końcu całkowicie zorientowany obiektowo!

Teraz, kiedy idziesz na plażę, programiści C ++ nie kopią piasku w twarz i nie kradną twojej (dziewczyny / chłopaka - wybierz jedną). I możesz nadal zakoduj pełny bilans próbny księgi głównej, gdy próbują dowiedzieć się, które pliki nagłówkowe mają zostać uwzględnione.

Po raz pierwszy możesz kodować tak blisko chipa, jak potrzebujesz i mieć dostęp do wszystkich wewnętrznych elementów systemu, jakich pragnie twoje serce bez uciekając się do tych nieprzyjemnych wywołań API Win32. Masz dziedziczenie, przeciążenie funkcji, asynchroniczne wielowątkowość, odśmiecanie i wszystko jest przedmiotem. Czy życie może być lepsze?

Czy słyszałem, że ktoś mówi, że C ++ ma wiele elementów dziedziczenia, a .NET nadal nie?

Spal heretyka!