Петте най-големи промени от VB 6 към VB.NET

Visual Basic 1.0 беше голямо земетресение по време на програмирането. Преди VB1 трябваше да използвате C, C ++ или друга ужасна среда за разработка, за да създадете Windows приложения. Програмистите буквално прекараха седмици, само рисувайки прозорци по екраните с придирчив, детайлен, труден за отстраняване на грешки код. (Същото нещо, което можете да направите, като плъзнете формуляр от лентата с инструменти за няколко секунди.) VB1 беше хит и газилиони програмисти веднага започнаха да го използват.

Но за да се случи магията, Microsoft направи някои големи компромиси с архитектурата. По-специално, тъй като VB1 създаде формулярите и контролите, те не разрешават на програмиста достъп до кода, който го направи. Или оставяте VB да създава всичко, или сте използвали C ++.

VB 2 до 6 поддържаха същата архитектура. Microsoft направи няколко много интелигентни актуализации, които дадоха на програмистите много повече контрол, но в краен случай програмистите все още не можаха да интегрират кода си с VB кода. Това беше черна кутия - и то не по добрия начин на OOP. Друг начин да се каже това е, че програмистът няма достъп до вътрешните VB „обекти“ и друг начин да каже, че VB6 все още не е напълно „обектно ориентиран“.

Междувременно започнаха да се появяват Java, Python и още куп други програмни езици, които WERE обектно ориентирани. Visual Basic се предаваше - голямо време! Това е ситуация, която Microsoft не понася... и те решиха да разрешат проблема веднъж завинаги. Решението е .NET.

Но за да направи нещата, които .NET трябваше да направи, Microsoft реши, че трябва да "нарушат съвместимостта". Тоест Visual Basic програмите бяха (с много малки изключения) „нагоре съвместими“ от VB1 чак до VB6. Програма, написана в тази първа версия на VB, все още ще се компилира и изпълнява в следващата версия. Но с VB.NET Microsoft установи, че те просто не могат да направят езика напълно OOP и да поддържат възходяща съвместимост.

След като взеха това фундаментално решение, портите от наводнения се отвориха след десет години натрупани промени в списъка с желания и ВСИЧКИ от тях влязоха в новия VB.NET. Както казват във Великобритания: „За една стотинка, за килограм“.

Без допълнително забавяне, ето моят много личен списък на първите пет промени от VB6 към VB.NET в обратен ред.

Wellllll... само едно допълнително забавяне. Тъй като се променяме от VB6, където масив, деклариран като Dim myArray (5) има 6 елементи, имаме шест от тях. Тя е подходяща само ...

(Моля, барабан, моля ...)

„Награда (5)“, нашата 6-то място наградата отива за избор на групи от C: Промени в синтаксиса като C!

Сега можете да кодирате + = 1, вместо a = a + 1, спестявайки ТРИ ЦЯЛИ КЛЮЧА!

Световните програмисти, радвайте се! VB е повишен до ниво C и цяло ново поколение, което се опитва да научи VB, ще се доближи малко до масовото объркване, което изправя учениците от C ++.

Но почакай! Има още!

VB.NET вече разполага с "логика на късо съединение", която от години въвежда фини грешки в C ++ код, за да спести ценни наносекунди от процесорното време. Логиката на късо съединение оценява само няколко условия в логическото изявление, ако е необходимо. Например:

Dim R като булева
R = функция1 () и функция2 ()

В VB6 и двете функции се оценяват дали имат нужда или не. При VB.NET, ако Function1 () е невярно, Function2 () се игнорира, тъй като „R“ не може да бъде True. Но какво ще стане, ако глобална променлива се промени във Function2 () - съвсем случайно (програмисти на C ++ биха казали „от лошо програмиране ".) Защо кодът ми дава грешен отговор в някои от случаите, когато е преведен VB.NET? Това може да е това!

За Опитвамing по-трудно, VB.NET ще улов малко късмет и накрая да бъдат разпознати за "изключителни" обработки на грешки.

VB6 имаше последния задържан GoTo: „При грешка GoTo“. Дори трябва да призная, че обработката на изключения в C ++ „Try-Catch-End“ структурирано управление на изключенията е огромно подобрение, а не просто подобрение на половината.

Какво, казвате, че „При грешка GoTo“ все още е във VB.NET? Wellll... Опитваме се да не говорим за това твърде много.

5-то място селекцията е групова награда: Различните команди се променят! Те трябва да споделят тази награда и ги има милион. Microsoft пестят от десет години и те наистина се освободиха.

VB.NET вече не поддържа функции VarPtr, ObjPtr и StrPtr, които извличат адреса на паметта на променливи. И не поддържа VB6 LSet, който се използва за преобразуване на един определен от потребителя тип в друг. (Да не се бърка с VB6 LSet, който прави нещо съвсем различно - вижте по-долу.)

Предлагаме също така за предпочитане adieu на Let, Is липсва, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar и (мой личен фаворит!) GoSub.

Кръгът се е превърнал в GDI + DrawEllipse. Същото важи и за Line to DrawLine. В изчислението вече имаме Atan вместо Atn, Sign влиза за Sgn, а Sqrt подхожда за голямата игра вместо Sqr.

При струнна обработка, въпреки че те все още са достъпни, ако се позовавате на съвместимост на Microsoft пространство за имена, имаме PadRight за LSet на VB6 (отново, напълно различен от LSet на VB6, разбира се) и PadLeft за RSet. (Следват трите натискания на клавиши, които запазихме с "+ ="!)

И разбира се, тъй като сега сме на OOP, не се притеснявайте, ако Set VB, Property Let и Property Get не са изпълнени във VB.NET, залагате!

И накрая, Debug. Отпечатването става или Debug. Пишете или отстранете грешката. WriteLine. Само ловците печатат всичко така или иначе.

Това дори не докосва всички НОВИ команди в VB.NET, но ние трябва да спрем тези глупости някъде.

в 4-то място, ние имаме Промени в процедурни повиквания!

Това е наградата за "доброта, чистота и добродетел" и представлява много тежка кампания от страна на фракцията "няма повече помия".

В VB6, ако променливата параметър на процедурата е присъщ тип, тогава това е ByRef, освен ако не сте го кодирали ByVal изрично, но ако не е кодиран ByRef или ByVal и не е присъща променлива, тогава е ByVal... Разбра ли?

В VB.NET това е ByVal, освен ако не е кодиран ByRef.

Между другото по подразбиране ByVal VB.NET също така предотвратява промяната на променливите на параметрите в процедурите неволно да се разпространява обратно в извикващия код - ключова част от доброто OOP програмиране.

Microsoft също "претоварва" VB.NET с промяна в изискванията за скоби при процедурни повиквания.

В VB6 се изискват скоби около аргументи при извършване на функционални повиквания, но не и при извикване на подпрограма, когато не се използва операторът Call, но те се изискват, когато се използва операторът Call.

Във VB.NET винаги се изискват скоби около непразен аргументен списък.

Бронзовата награда - 3-то място, отива Масивите са 0 базирани вместо 1 базирани!

Това е само една промяна в синтаксиса, но тази промяна придобива статут на "медален подиум", защото е гласувана, "най-вероятно да прецакате логиката на вашата програма". Не забравяйте, 3-то място IS „Награда (2)“ в нашия списък. Ако имате броячи и масиви във вашата VB6 програма (и колко не), този ще ви НАМЕРЕТЕ.

Десет години хората питат: "Какво пушеше Microsoft, когато го направиха по този начин?" И от десет години програмисти имат нещо като универсално пренебрегна факта, че имаше елемент myArray (0), който просто зае място и не свикна с нищо... С изключение на тези програмисти, които DID го използват и техните програми изглеждаха, искам да кажа, просто "странно".

За I = 1 до 5
MyArray (I - 1) = Каквото и да е
Следващия

Имам предвид, НАИСТИНА ЛИ! ...

Сребърният медал на 2-ро място отива да почете стар приятел, който беше изпуснат в малкото кофа за програмиране с преминаването на VB6! Не говоря за друго, Вариантният тип данни.

Вероятно никоя друга единична функция на „notNet“ на Visual Basic не представя по-добре философията на „бързо, евтино и свободно“. Това изображение прехвърли VB чак до въвеждането на VB.NET. Достатъчно стар съм, за да си спомням въвеждането на Visual Basic 3.0 от Microsoft: „О, уау! Ето тук! С новия, подобрен тип данни на Variant, не е нужно да декларирате променливи или нищо. Можете просто да ги помислите и да ги кодирате. "

Microsoft промениха мелодията си доста бързо и препоръчаха деклариране на променливи с a специфичен тип данни почти веднага, което оставя много от нас да се чудят: „Ако не можете да използвате Варианти, защо имат ли ги? "

Но докато сме на тема типове данни, трябва да спомена, че много типове данни са се променили в допълнение към попадането на Variant във влажен цимент. Има нов тип данни на Char и дълъг тип данни, който е 64 бита. Десетичната е по различен начин. Short и Integer вече не са еднакви по дължина.

И има нов тип данни "Обект", който може да бъде нищо. Чух ли някой да казва: "Син на варианта"?

Най-накрая! Златният медал, 1-во място, най-високата награда, на която мога да я дам ...

TA DAH!

VB.NET най-накрая е напълно обектно ориентиран!

Сега, когато отидете на плажа, програмистите на C ++ няма да ритат пясък в лицето и ще ви откраднат (приятелка / гадже - изберете един). И вие можете все още кодирайте пълен пробен баланс на главната книга, докато те се опитват да разберат кои файлове със заглавия да включат.

За първи път можете да кодирате колкото е възможно по-близо до чипа и да имате достъп до всички вътрешни системи, които сърцето ви желае без трябва да прибягвате до тези гадни Win32 API обаждания. Имате наследяване, претоварване на функции, асинхронно многопоточност, събиране на боклука и всичко е обект. Може ли животът да се подобри?

Чух ли някой да каже, че C ++ има множество наследявания и .NET все още не?

Изгори еретика!