Les cinq principaux changements de VB 6 à VB.NET

Visual Basic 1.0 a été un tremblement de terre majeur tout au long de la programmation. Avant VB1, vous deviez utiliser C, C ++ ou un autre horrible environnement de développement pour créer des applications Windows. Les programmeurs ont littéralement passé des semaines à dessiner des fenêtres sur des écrans avec un code difficile, détaillé et difficile à déboguer. (La même chose que vous pouvez faire en faisant glisser un formulaire de la barre d'outils en quelques secondes.) VB1 a été un succès et des millions de programmeurs ont immédiatement commencé à l'utiliser.

Mais pour que la magie opère, Microsoft a fait des compromis majeurs sur l'architecture. En particulier, puisque VB1 a créé les formulaires et les contrôles, ils n'ont pas permis au programmeur d'accéder au code qui l'a fait. Soit vous laissez VB tout créer, soit vous utilisez C ++.

Les VB 2 à 6 ont conservé cette même architecture. Microsoft a fait des mises à jour très intelligentes qui ont donné aux programmeurs beaucoup plus de contrôle, mais en dernière analyse, les programmeurs ne pouvaient toujours pas intégrer leur code avec le code VB. C'était une boîte noire - et pas dans le bon sens de la POO non plus. Une autre façon de le dire était que le programmeur n'avait pas accès aux "objets" internes du VB et une autre façon de dire que le VB6 n'était toujours pas complètement "orienté objet".

Entre-temps, Java, Python et beaucoup d'autres langages de programmation orientés objet ont commencé à apparaître. Visual Basic se faisait passer - grand temps! C'est une situation que Microsoft ne tolère pas... et ils ont résolu de résoudre le problème une fois pour toutes. La solution est .NET.

Mais pour faire les choses que .NET devait faire, Microsoft a décidé qu'il fallait "casser la compatibilité". C'est-à-dire que les programmes Visual Basic étaient (à de très rares exceptions près) "à la hausse" de VB1 jusqu'à VB6. Un programme écrit dans cette première version de VB serait toujours compilé et exécuté dans la prochaine version. Mais avec VB.NET, Microsoft a constaté qu'ils ne pouvaient tout simplement pas rendre le langage complètement OOP et maintenir une compatibilité ascendante.

Une fois qu'ils ont pris cette décision fondamentale, les vannes se sont ouvertes sur dix ans de changements de "liste de souhaits" accumulés et TOUS ont été intégrés dans le nouveau VB.NET. Comme on dit en Grande-Bretagne, "Pour un sou, pour une livre."

Sans plus tarder, voici ma liste très personnelle des cinq principaux changements de VB6 à VB.NET dans l'ordre inverse.

Wellllll... juste un retard supplémentaire. Puisque nous changeons de VB6, où un tableau déclaré comme Dim myArray (5) a 6 éléments, nous en avons six. C'est juste approprié ...

(Roulement de tambour s'il vous plaît ...)

"Award (5)", notre 6e place le prix revient au choix des groupies C: Changements de syntaxe de type C!

Vous pouvez maintenant coder a + = 1 au lieu de a = a + 1, économisant TROIS TOUCHES DE TOUCHE!

Programmeurs du monde, réjouissez-vous! Le VB a été élevé au niveau C, et toute une nouvelle génération essayant d'apprendre le VB se rapprochera un peu de la confusion de masse qui confronte les étudiants de C ++.

Mais attendez! Il y a plus!

VB.NET propose désormais une "logique de court-circuit" qui a introduit des bogues subtils dans le code C ++ pendant des années pour économiser de précieuses nano-secondes de temps processeur. La logique de court-circuit n'évalue plusieurs conditions dans une instruction logique que si nécessaire. Par exemple:

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

Dans VB6, les deux fonctions sont évaluées, qu'elles en aient besoin ou non. Avec VB.NET, si Function1 () est false, Function2 () est ignoré car "R" ne peut pas être True. Mais que se passe-t-il si une variable globale est modifiée dans Function2 () - juste par hasard (les programmeurs C ++ diraient: "par mauvaise programmation ".) Pourquoi mon code produit-il parfois une mauvaise réponse lorsqu'il est traduit en VB.NET? C'est peut-être ça!

Pour Essayerplus difficile, VB.NET Capture un peu de chance et finalement être reconnu pour la gestion des erreurs "exceptionnelle".

VB6 avait le dernier blocage GoTo: "On Error GoTo". Même moi, je dois admettre que la gestion des exceptions structurées de style C ++ "Try-Catch-Final" est une vaste amélioration, pas seulement une amélioration à moitié.

Quoi, vous dites que "On Error GoTo" est toujours dans VB.NET? Eh bien... Nous essayons de ne pas trop en parler.

5e place la sélection est un prix de groupe: La commande diverse change! Ils doivent partager ce prix et il y en a des millions. Microsoft économise depuis dix ans et ils se sont vraiment détachés.

VB.NET ne prend plus en charge les fonctions VarPtr, ObjPtr et StrPtr qui ont récupéré l'adresse mémoire des variables. Et il ne prend pas en charge VB6 LSet qui a été utilisé pour convertir un type défini par l'utilisateur en un autre. (À ne pas confondre avec VB6 LSet qui fait quelque chose de complètement différent - voir ci-dessous.)

Nous souhaitons également beaucoup de plaisir à Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar et (mon préféré!) GoSub.

Le cercle s'est transformé en GDI + DrawEllipse. Il en va de même pour Line to DrawLine. Dans le calcul, nous avons maintenant Atan au lieu d'Atn, Sign entre en Sgn et Sqrt se prépare pour le grand jeu au lieu de Sqr.

Dans le traitement des chaînes, même si elles sont toujours disponibles si vous faites référence à une compatibilité Microsoft espace de noms, nous avons PadRight pour LSet de VB6 (encore une fois, totalement différent de LSet de VB6, bien sûr) et PadLeft pour RSet. (Il y a les trois touches que nous avons enregistrées avec "+ ="!)

Et bien sûr, puisque nous sommes OOP maintenant, ne vous inquiétez pas si Property Set, Property Let et Property Get ne sont pas respectés dans VB.NET, vous pariez!

Enfin, déboguez. L'impression devient soit Debug. Écrire ou déboguer. WriteLine. De toute façon, seuls les nerds impriment tout.

Cela ne touche même pas toutes les NOUVELLES commandes de VB.NET, mais nous devons arrêter ce non-sens quelque part.

Dans 4e place, on a Modifications des appels de procédure!

Il s'agit du prix «bonté, pureté et vertu saine» et représente beaucoup de campagne acharnée menée par la faction «plus de code bâclé».

Dans VB6, si une variable de paramètre de procédure est de type intrinsèque, alors c'est ByRef, sauf si vous l'avez codée ByVal explicitement, mais si ce n'est pas codé ByRef ou ByVal et ce n'est pas une variable intrinsèque, alors c'est ByVal... C'est compris?

Dans VB.NET, c'est ByVal à moins qu'il ne soit codé ByRef.

La valeur par défaut de ByVal VB.NET, en passant, empêche également les modifications des variables de paramètre dans les procédures d'être propagées involontairement dans le code appelant - un élément clé d'une bonne programmation OOP.

Microsoft «surcharge» également VB.NET avec une modification des exigences de parenthèses dans les appels de procédure.

Dans VB6, des parenthèses sont requises autour des arguments lors des appels de fonction, mais pas lors de l'appel d'un sous-programme lorsque vous n'utilisez pas l'instruction Call, mais elles sont obligatoires lorsque l'instruction Call est utilisée.

Dans VB.NET, des parenthèses sont toujours requises autour d'une liste d'arguments non vide.

Le prix Bronze - 3ème place, va à Les tableaux sont basés sur 0 au lieu de 1!

Ce n'est qu'un changement de syntaxe, mais ce changement obtient le statut de "podium des médailles" car il est voté, "le plus susceptible de bousiller la logique de votre programme". Rappelez-vous, 3e place EST "Award (2)" dans notre liste. Si vous avez des compteurs et des tableaux dans votre programme VB6 (et combien n'en ont pas), celui-ci vous MESSERA.

Depuis dix ans, les gens demandent: "Qu'est-ce que Microsoft fumait quand ils l'ont fait de cette façon?" Et depuis dix ans, les programmeurs ont sorte de universellement ignoré le fait qu'il y avait un élément myArray (0) qui a juste pris de l'espace et n'a pas été utilisé pour n'importe quoi... Sauf pour les programmeurs qui l'ont utilisé et leurs programmes semblaient, je veux dire, juste "bizarres".

Pour I = 1 à 5
MyArray (I - 1) = Peu importe
Prochain

Je veux dire, VRAIMENT! ...

La médaille d'argent de 2ème place va honorer un vieil ami qui a été abandonné dans le seau de bits de programmation avec le passage de VB6! Je ne parle de rien d'autre que, Le type de données variant.

Probablement aucune autre fonctionnalité unique de Visual Basic "notNet" ne représente mieux la philosophie du "rapide, bon marché et lâche". Cette image tenace VB jusqu'à l'introduction de VB.NET. Je suis assez vieux pour me souvenir de l'introduction de Visual Basic 3.0 par Microsoft: "Oh Wow! Regardez ici! Avec le nouveau type de données Variant amélioré, vous n'avez pas à déclarer de variables ou rien. Vous pouvez simplement les penser et les coder. "

Microsoft a changé son air assez rapidement sur celui-ci et a recommandé de déclarer les variables avec un type de données spécifique presque immédiatement, laissant beaucoup d'entre nous se demander: "Si vous ne pouvez pas utiliser des variantes, pourquoi les avoir?"

Mais alors que nous parlons de types de données, je dois mentionner que beaucoup de types de données ont changé en plus de déposer Variant dans du ciment humide. Il existe un nouveau type de données Char et un type de données Long de 64 bits. Décimal est bien différent. Short et Integer ne sont plus de la même longueur.

Et il existe un nouveau type de données "Objet" qui peut être n'importe quoi. Ai-je entendu quelqu'un dire: "Fils de variante"?

Finalement! La médaille d'or, 1ère place, la plus haute distinction que je puisse décerner est décernée à ...

ET VOILÀ!

VB.NET est enfin complètement orienté objet!

Maintenant, quand vous allez à la plage, les programmeurs C ++ ne vous frapperont pas le visage et ne vous voleront pas (petite amie / petit ami - choisissez-en un). Et tu peux encore coder un solde d'essai complet du grand livre général pendant qu'ils essaient de déterminer les fichiers d'en-tête à inclure.

Pour la première fois, vous pouvez coder aussi près de la puce que vous le souhaitez et accéder à tous les éléments internes du système que votre cœur désire sans pour autant avoir à recourir à ces méchants appels API Win32. Vous avez l'héritage, la surcharge de fonctions, le multithreading asynchrone, le garbage collection et tout est un objet. La vie peut-elle s'améliorer?

Ai-je entendu quelqu'un dire que C ++ a plusieurs héritages et que .NET ne fonctionne toujours pas?

Brûlez l'hérétique!