Visual Basic n’est pas encore mort

Visual Basic n’est pas encore mort
Microsoft annonce les changements apportés à la version 14 du langage

Le premier langage de programmation qui nous passe par la tête quand on pense à la programmation .Net c’est le C#. Cependant, Visual Basic n’a pas encore été abandonné par Microsoft et pour cause, ce langage reste encore très utilisé dans les écoles, mais aussi par plusieurs développeurs qui ne veulent pas changer de langage, d’autant plus que côté performances il n’a rien à se reprocher par rapport à C#, puisqu’il utilise le même IDE et les mêmes binaires.

Hier, Microsoft a annoncé les nouveautés apportées à Visual Basic 14 (la version 13 ayant été ignorée pour rester dans le même numéro de version que l’IDE). Parmi ces nouveautés, on peut citer l’introduction de l’opérateur « ?. » dont le but est de vérifier si une variable, une propriété ou un objet est nul avant de tenter d’y accéder, ou aussi pour vérifier si on est en train d’invoquer une méthode d’une référence qui n’existe pas. Par exemple, le code suivant :

Code:

---

If customer IsNot Nothing AndAlso customer.Age > 100 Then

---

Deviendra :

Code:

---

If customer?.Age > 100 Then

---

Lucian Wischik explique sur MSDN que l'opérateur « ?. » est plus sûr puisque dans l’exemple « l’expression "customer?.Age" lit la variable customer dans une variable temporaire, vérifie si elle n’est pas nulle, puis récupère la propriété Age de cette variable temporaire. Ce qui est thread-safe même si customer est nul ».

Un autre changement qu’on peut citer aussi est que les propriétés en lecture seule (Readonly) peuvent désormais être déclarées et initialisées directement dans la même ligne, comme montré dans la figure suivante :

http://www.developpez.com/public/images/news/vb14.gif
Nouvelle manière d'initialiser les propriétés Readonly, Source : MSDN

Concernant les chaines de caractères, il n’est plus nécessaire d’ajouter des & à la fin de la ligne pour indiquer qu’elles s’étendent sur la ligne suivante, puisque le compilateur détecte cela automatiquement à présent. De plus, il existe une autre manière de les formater en utilisant l’interpolation de chaines (String Interpolation). Donc au lieu d’écrire :

Code:

---

String url = String.Format("http://{0}/{1}?query={2}", site, path, q) ;

---

On écrira :

Code:

---

String url = $"http://{site}/{path}?query={q}";

---

À noter que cette dernière fonctionnalité n’est pas encore disponible dans la preview de Visual Studio 2015, mais sera intégrée dans la version finale. Vous pouvez consulter ici la liste de tous les changements apportés jusqu’à maintenant et ceux qui vont venir.

Source : Blog MSDN

Et vous ?

:fleche: Qu’en pensez-vous ? Quelles nouveautés voulez-vous voir intégrées au langage ?

le ? c'est bien, avec copie thread safe c'est encore mieux, bien qu'il arrive qu'on ait plusieurs propriétés à tester dans un thread auquel cas une copie de toutes à un instant T puisse rester nécessaire

le readonly property en une seule ligne je me demandais pourquoi il ne l'ont pas mis en même temps que les properties en une seule ligne, cool aussi

le string sur plusieurs lignes à la facon d'sql server c'est bien aussi

concernant la fabrication de string, je reste plus sceptique, une variable en chaine de caractère ca reste caduque en terme de vérification à la compilation
je pense que dans ce cas il n'y a pas de vérification, mais ca reste possible donc s'ils l'ont mis c'est bien, mais ca reste une syntaxe que je n'utiliserais pas

j'ai regardé un peu la liste des nouveautés, j'aime bien le NameOf() qui est aussi un point sécuritaire plutot que de compiler un string qui peut être faux

content de voir que vb continue son chemin, par contre il reste à déplorer que ce n'est pas un langage prioritaire dans beaucoup de choses
à priori si j'ai bien suivi sur .net micro framework c# est arrivé en 1er, sur xamarin c'est pareil le c# est possible, mais pas vb.net
c'est un langage qui a une mauvaise réputation, comme sa communauté de développeur considérée comme débutante, alors que bien utilisé il n'a rien à envier à c# et je trouve ca vien d'avoir une alternative sur la syntaxe en gardant les bases de .net

Hello,

Pareil que Pol63 concernant les changements évoqués. Autant les premiers sont les bienvenus, autant le dernier concernant les chaînes de caractères me semble douteux. Je trouve quand même l'ancienne écriture bien plus lisible !

Ou alors il aurait fallu faire changer la couleur des noms de variables qui sont entre les accolades... Enfin ce n'est que mon avis.

Sinon, concernant le débat entre VB et C#, comme cela a déjà été dit, le VB n'a rien à envier au C# et le fait que VB soit délaissé pour pas mal de choses est vraiment regrettable.

A l'école, j'ai appris le VB6, quand je suis passé à .NET par curiosité avec le framework 1, je suis logiquement passé sur VB.NET et j'ai assez vite retrouvé mes jeunes.

Dernièrement je me suis mis à C# histoire de faire un petit projet perso avec XNA et franchement, je trouve le C# bien moins clair en lecture que le VB.NET. Un reproche qui est souvent fait à VB est d'être trop verbeux. Je trouve personnellement que c'est justement une qualité et pas un défaut.

C'est quand même beaucoup plus lisible d'avoir les End If, End While, End For, etc. au lieu d'une série d'accolade fermante "}". Et quand en plus VS n'indente pas les accolades correctement*, ça devient vite le bordel.

*J'ai d'ailleurs été très étonné qu'un truc aussi basic soit mal fait pour le C#. Une chose de ce genre ne m'est jamais arrivée en VB.NET. A moins que ce soit propre à l'utilisation de XNA ??

My 2 cents...

Bonjour,
depuis la version 3 Microsoft nous à vendu Vb comme un langage instinctif! comme si l'instinct était de mise en programmation professionnel!

des le début Vb avait de quoi devenir un grand langage, la notion de classe était embryonnaire mais présente; le Visuel Basic Application à compliqué la donne reléguant le Vb à un rôle de bidouillage de deuxième zone pour développeur spaghettis et/ou procédural!

cette mauvaise réputation est due en partie à cela mais également au recruteur qui déroule un discourt qui ne comprenne pas.

je suis un pur produit Vb et je suis ravis de voir que vb continue moi aussi!

Citation:

---

Envoyé par Amine Horseman

Visual Basic n’est pas encore mort

---

En même temps je ne crois pas avoir entendu qui que ce soit dire qu'il l'était ;)

Citation:

---

Envoyé par Pol63

concernant la fabrication de string, je reste plus sceptique, une variable en chaine de caractère ca reste caduque en terme de vérification à la compilation
je pense que dans ce cas il n'y a pas de vérification, mais ca reste possible donc s'ils l'ont mis c'est bien, mais ca reste une syntaxe que je n'utiliserais pas

---

Si, c'est vérifié par le compilateur. En fait, le compilateur transforme l'expression d'interpolation en un string.Format équivalent. Si tu écris ça :

Code:

---

String url = $"http://{site}/{path}?query={q}";

---

le compilateur le transforme en ça :

Code:

---

String url = string.Format("http://{0}/{1}?query={2}", site, path, q);

---

et vérifie normalement les expressions "path", "site" et "q"

Tu auras même l'intellisense dans ta string ;)

Je rejoins les avis précédent, particulièrement pour le ?. Le fameux IsNot Nothing de la variable c'était pas le top point de vue lisibilité du code.

Quand au débat c# et VB, je trouve qu'il n'a pas vraiment lieu d'être parce que c'est surtout une histoire de syntaxe.

Si c# a tendance a être plus proche de java, de faire du code condensé (d'un point de vue nombre de caractère) et en théorie d'avoir une meilleur productivité en écriture de code au kilomètre. J'aime beaucoup le coté verbeux de Visual Basic qui rend le code beaucoup plus human readable.

Je dois pas être fichu comme tout le monde parce que l'histoire du ? je suis pas 100% fan ; je comprends l'intérêt mais pour moi ça va créer des incohérences dans l'écriture pour la simple et bonne raison que ça marchera bien pour les éléments intermédiaires mais pour l'élément final on sera toujours dans la même situation qu'avant du coup on va se retrouver à faire des choses de ce style :

Code:

---

1 2	If customer?.Orders IsNot Nothing Then ' propriété If dict?(key) IsNot Nothing Then ' indexeur

---

le problème serait le même avec C# a priori (sauf si bien sûr j'ai loupé un détail et que ce genre de chose là est possible)

Code:

---

1 2	If customer?.Orders? Then If dict?(key)? Then

---

Mais dans un cas comme dans l'autre ça me laisse un brin perplexe ; dans le premier cas on se retrouve à miser les 2 façons et du coup ça peut être déstabilisant (pourquoi fait-on différemment ?) et dans le second je trouve ça peu lisible et c'est vite fait de louper ce ? final (le compilo nous le signalera vite mais quand même).

Pour l'interpolation de chaine ça me permettra au moins de ranger au placard mon FormatNamed "maison" :D

Quant à la productivité de l'un ou l'autre langage ; personnellement je pense que c'est plus une question d'IDE que de langage (et de ce point de vue là VS pour VB.Net complète suffisamment la "verbosité" pour éliminer totalement [si ce n'est inverser] les choses)

J'aurais quand même aimé avoir 2-3 petites choses qui n'y sont malheureusement pas (par exemple la possibilité d'activer/désactiver localement le late binding ou l'overflow check [resp. dynamic et checked/unchecked en C#] plutôt que d'avoir un réglage global au niveau du projet [à voir s'il y a quelque chose de dispo dans le principe du #pragma qui semble avoir été ajouté])

Il y a une compatibilité avec les "anciennes écriture" du code au niveau du compilateur ?
Le linker n'ayant pas besoin de savoir sa.

Bonjour à tous,

Je ne me suis pas encore documenté sur les versions à venir, mais je suis d'accord avec tout le monde, ces évolutions sont utiles et nécessaires.
Bien que je trouve que la syntaxe s'éloigne un peu du VB, mais bon, c'est pas génant et on s'y fait rapidement.

Je crois que le VB c'est comme la potion magique de Asterix, et nous sommes tous des Obelix... nous sommes tombés dedans étant petits...

Perso, j'ai commencé avec le ZX Spectrum en 86 ou 87 je crois (je sais ça ne me rajeuni pas) :D
si vous cliquez sur l'image vous verrez que chaque touche contient déjà des instructions en basic...

Je n'ai aucun problème à reprendre ou à faire une application en C# ou Java (notamment pour Android).
Mais à des moments donnés quand j'ai besoin de quelque chose bien spécifique, je me retrouve avec un bout de code en VB traduit en C#...

En parlant de Android, j'ai bien sur commencé en Java au début, bon, il faut se familiariser à la structure des applications etc.
Et puis, depuis quelques mois j'ai découvert Basic4android.
Un excellent travail de compilation VB/Java fait par Anywhere Software, depuis je n'utilise que ça, je viens d'équiper un amphithéâtre dans une université avec une tablette Android et une application en VB!...

Comme dit rdurupt, je suis ravis de voir que vb continue moi aussi!

A+

Bonjour, je suis moins pro que mes camarades au dessus concernant le VB.Net mais j'utilise en majorité ce langage, et ceux pour des raisons simples : il est clair et plein d'outils très utiles.
Je suis très content de voir qu'il y a une évolution du langage qui simplifie à la fois l'écriture et la lecture du code, en espérant que l'évolution se poursuive de façon active.

Citation:

---

Envoyé par ACIVE_CS

En parlant de Android, j'ai bien sur commencé en Java au début, bon, il faut se familiariser à la structure des applications etc.
Et puis, depuis quelques mois j'ai découvert Basic4android.

---

merci pour l'info

bonjour

L'amelioration concernant du test concernant les types references me parait etre une fausse amelioration ...
Jugez-en
En .Net 1.1 le malheureux codeur devait ecrire cette longue ligne (IsNot n'exisait pas) totalement incomprehensible :

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If Not (cust Is Nothing) Then   End If End Sub

---

En .Net 2.0 ,l'operateur IsNot (la negation d'un type reference en c#) est "invente",un de plus...On est soulage:

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If cust IsNot Nothing Then   End If End Sub

---

Maintenant ce qu'il faut c'est eliminer le AndAlso et avoir un seul And comme en c# qui fait le "court-circuit" pour les types references ...
on aurait bien aime ecrire comme en c# le code d'exemple cite :

Code:

---

1 2 3

If customer IsNot Nothing And customer.Age > 100 Then

---

....
Qu'en est-il de l'inconvenient "debile" de la declaration de tableaux comme l'as bien releve Tomlev ou vous specifier un tableau à 2 dimensions comme suit :

Code:

---

1 2	Private Customers(1) As Customer

---

La mise en conformite serait la bienvenue ... !!!

J'ai rien compris :aie:
Dire que Not cust Is Nothing est trop long est un non sens (ça ne fait qu'un seul caractère de moins que cust IsNot Nothing) pour la lisibilité en revanche je suis un peu d'accord c'est pas génial (c'est pas catastrophique non plus)
L'histoire sur le And et le AndAlso là je suis carrément paumé ; en C# on a aussi & et && donc je vois pas le souci à en avoir 2 ; leurs rôles respectif sont clairement définis.
Quant aux tableaux, je ne suis pas sûr d'avoir compris, si c'est le "problème" d'avoir à écrire 1 là où ça donne 2 éléments ; ce n'est pas près de changer ; il a toujours été précisé que ce qu'on donne sont les bornes des dimensions pas la taille de la dimension (après on aime ou on aime pas mais c'est comme ça et ça représenterait un trop gros breaking change pour que ça change un jour à mon avis)

Citation:

---

Envoyé par Sehnsucht

L'histoire sur le And et le AndAlso là je suis carrément paumé ; en C# on a aussi & et && donc je vois pas le souci à en avoir 2 ; leurs rôles respectif sont clairement définis.

---

les opérateurs AND et & (dont j'ignorais l'existence en tant qu'opérateur de test) ont l'inconvénient de systématiquement évaluer les 2 expressions de chaque coté de l'opérateur avant d'en déduire le résultat. Il faut donc prendre garde qu'elles soient toutes les 2 évaluables et donc multiplier les tests. Le AND est un héritage des anciens VB et surtout des Basic.

Les opérateurs ANDALSO et && sont les opérateurs de test ET LOGIQUE des langages à la syntaxe C like. Ici, la seconde expression n'est évaluée que et seulement que si l'évaluation de la première n'a pas permis de déterminer le résultat du test. C'est un fonctionnement qui beaucoup plus logique en informatique et en développement, et dans tout domaine de manière générale. Inutile de désosser le moteur de la voiture à partir du moment que l'on sait que la panne est due à un réservoir vide.

L'opérateur AND (et donc maintenant & en C#) est une aberration en soi dans nos programmations modernes. Je fais parti des fervent militants (même déjà au temps de VB6) pour l'abandon pur et simple de cet opérateur.
Il en va de même pour l'opérateur OR qui devrait être abandonné au profit du ORELSE (ainsi que de la boucle FOR qui devrait fonctionner comme dans les langages C like)

Citation:

---

Envoyé par MABROUKI

L'amelioration concernant du test concernant les types references me parait etre une fausse amelioration ...
Jugez-en
En .Net 1.1 le malheureux codeur devait ecrire cette longue ligne (IsNot n'exisait pas) totalement incomprehensible :

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If Not (cust Is Nothing) Then   End If End Sub

---

En .Net 2.0 ,l'operateur IsNot (la negation d'un type reference en c#) est "invente",un de plus...On est soulage:

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If cust IsNot Nothing Then   End If End Sub

---

Maintenant ce qu'il faut c'est eliminer le AndAlso et avoir un seul And comme en c# qui fait le "court-circuit" pour les types references ...
on aurait bien aime ecrire comme en c# le code d'exemple cite :

Code:

---

1 2 3

If customer IsNot Nothing And customer.Age > 100 Then

---

---

And et AndAlso n'ont pas le même sens, et changer And pour qu'il fasse la même chose que AndAlso serait une très mauvaise idée (ça pourrait casser du code existant).

Sinon, j'ai l'impression que tu n'as pas bien compris le but de cette amélioration... Ce sera peut-être plus clair avec un exemple plus extrême ; tu préfères écrire ça :

Code:

---

1 2 3 4

Dim city As String = "(unknown)" If order IsNot Nothing AndAlso order.Customer IsNot Nothing AndAlso order.Customer.Address IsNot Nothing AndAlso order.Customer.Address.City IsNot Nothing Then city = order.Customer.Address.City End If

---

ou ça ?

Code:

---

Dim orderCity As String = If (order?.Customer?.Address?.City, "(unknown)")

---

En ce qui me concerne, le choix est vite fait...
(c'est également plus performant, car chaque propriété n'est évaluée qu'une seule fois)

Citation:

---

Envoyé par MABROUKI

Qu'en est-il de l'inconvenient "debile" de la declaration de tableaux comme l'as bien releve Tomlev ou vous specifier un tableau à 2 dimensions comme suit :

Code:

---

1 2	Private Customers(1) As Customer

---

La mise en conformite serait la bienvenue ... !!!

---

Oui, c'est un des trucs qui m'énervent en VB... mais malheureusement ça ne changera pas, puisque ce serait un breaking change.

Citation:

---

Envoyé par sevyc64

les opérateurs AND et & (dont j'ignorais l'existence en tant qu'opérateur de test) ont l'inconvénient de systématiquement évaluer les 2 expressions de chaque coté de l'opérateur avant d'en déduire le résultat. Il faut donc prendre garde qu'elles soient toutes les 2 évaluables et donc multiplier les tests. Le AND est un héritage des anciens VB et surtout des Basic.

Les opérateurs ANDALSO et && sont les opérateurs de test ET LOGIQUE des langages à la syntaxe C like. Ici, la seconde expression n'est évaluée que et seulement que si l'évaluation de la première n'a pas permis de déterminer le résultat du test. C'est un fonctionnement qui beaucoup plus logique en informatique et en développement, et dans tout domaine de manière générale. Inutile de désosser le moteur de la voiture à partir du moment que l'on sait que la panne est due à un réservoir vide.

L'opérateur AND (et donc maintenant & en C#) est une aberration en soi dans nos programmations modernes. Je fais parti des fervent militants (même déjà au temps de VB6) pour l'abandon pur et simple de cet opérateur.
Il en va de même pour l'opérateur OR qui devrait être abandonné au profit du ORELSE (ainsi que de la boucle FOR qui devrait fonctionner comme dans les langages C like)

---

Les opérateurs And, Or, & et | ont aussi leur utilité.

D'abord pour un cas d'usage où il 'y a pas d'alternative : les opérations de combinaisons de bits. Par exemple :

Code:

---

1 2	// prend les 2 octets de poids faible de y int x = y & 0x0000FFFF;

---

Ensuite parce qu'il peut y avoir des cas où tu veux évaluer les deux opérandes :

Code:

---

if (DoSomething() & DoSomethingElse())

---

Il est tout à fait légitime de vouloir exécuter les 2 opérations et tester si les deux ont renvoyé true. Maintenant, j'admets volontiers que ce n'est pas la façon la plus naturelle et la plus lisible de faire ça... d'ailleurs si je voyais un truc comme ça pendant une relecture de code, je demanderais certainement à l'auteur de le changer.

Enfin, on peut faire &=, ce qui est parfois utile, mais pas &&=...

Déjà je pense que pour la "suppression" c'est surtout concernant les vers logiques de ces opérateurs pas leurs versions numériques.
Après j'étais en train de rédiger grosso modo la même chose que tomlev (avec un joli If Foo () And Bar () Then en exemple :aie:) à laquelle j'allais quand même dire qu'à choisir je préfèrerais une approche de ce type :

Code:

---

1 2 3

Dim fooRes = Foo () Dim barRes = Bar () If fooRes AndAlso barRes Then

---

Comme quoi les "grands" esprits se rencontrent :haha:

Salut,

Moi aussi, mais tanpis, je poste quand même :D

----------------------------------------------------

Citation:

---

Envoyé par sevyc64

les opérateurs AND et & (dont j'ignorais l'existence en tant qu'opérateur de test) ont l'inconvénient de systématiquement évaluer les 2 expressions de chaque coté de l'opérateur avant d'en déduire le résultat. Il faut donc prendre garde qu'elles soient toutes les 2 évaluables et donc multiplier les tests. Le AND est un héritage des anciens VB et surtout des Basic.

Les opérateurs ANDALSO et && sont les opérateurs de test ET LOGIQUE des langages à la syntaxe C like. Ici, la seconde expression n'est évaluée que et seulement que si l'évaluation de la première n'a pas permis de déterminer le résultat du test. C'est un fonctionnement qui beaucoup plus logique en informatique et en développement, et dans tout domaine de manière générale. Inutile de désosser le moteur de la voiture à partir du moment que l'on sait que la panne est due à un réservoir vide.

L'opérateur AND (et donc maintenant & en C#) est une aberration en soi dans nos programmations modernes. Je fais parti des fervent militants (même déjà au temps de VB6) pour l'abandon pur et simple de cet opérateur.
Il en va de même pour l'opérateur OR qui devrait être abandonné au profit du ORELSE (ainsi que de la boucle FOR qui devrait fonctionner comme dans les langages C like)

---

Citation:

---

Envoyé par D'après les spec VB 11.0

Or : le bit de résultat est 1 si l'un des deux bits est 1 ; sinon, le bit de résultat est 0.
And : le bit de résultat est 1 si les deux bits sont 1 ; sinon, le bit de résultat est 0.
AndAlso et OrElse :Les opérateurs AndAlso et OrElse sont les versions « court-circuit » des opérateurs logiques And et Or. Du fait de leur comportement de court-circuit, le deuxième opérande n'est pas évalué au moment de l'exécution si le résultat de l'opérateur est connu après l'évaluation du premier opérande.
Les opérateurs logiques de court-circuit sont évalués de la façon suivante :
Si le premier opérande d'une opération AndAlso a la valeur False ou retourne True à partir de son opérateur IsFalse, l'expression retourne son premier opérande. Autrement, le deuxième opérande est évalué et une opération And logique est effectuée sur les deux résultats.

Si le premier opérande d'une opération OrElse a la valeur True ou retourne True à partir de son opérateur IsTrue, l'expression retourne son premier opérande. Autrement, le deuxième opérande est évalué et une opération Or logique est effectuée sur ses deux résultats.

---

Un petit test sur un champs de bit:

Code:

---

1 2 3 4 5 6 7 8

Enum BitField As Integer A = 0 ' 0000 B = 1 ' 0001 C = 2 ' 0010 D = 4 ' 0100 E = 8 ' 1000 End Enum

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Sub Main()   Dim Res(0 To 1) As Integer   ' ' A priori : 0000 ' OR 0001 ' = 0001 ' = 1 Res(0) = BitField.A Or BitField.B ' J'ai mis Option Strict Off pour l'opérateur OrElse Res(1) = BitField.A OrElse BitField.B   Res(0) = 0 : Res(1) = 0 ' ' A priori : 0001 ' OR 0001 ' = 0001 ' = 1 Res(0) = BitField.B Or BitField.B Res(1) = BitField.B OrElse BitField.B   Res(0) = 0 : Res(1) = 0   ' ' A priori : 0010 ' = 2 ' OR 1000 ' = 8 ' = 1010 ' = 10 Res(0) = BitField.C Or BitField.E Res(1) = BitField.C OrElse BitField.E

---

un modo peut supprimer les 5 posts qui flood à propos de and et andalso ? ^^

Citation:

---

Envoyé par Nouveau2

' J'ai mis Option Strict Off pour l'opérateur OrElse

---

Ça me rassure de voir que OrElse n'est pas autorisé sur des entiers en mode strict, parce que ça n'a pas vraiment de sens... OrElse et AndAlso ne fonctionnent qu'avec des opérandes booléens.

En mode non strict, si c'est des entiers, ils sont implicitement convertis en Boolean (False si c'est 0, sinon True). Et comme tu affectes le résultat à un entier, c'est reconverti implicitement en entier (-1 pour True, 0 pour False). Donc dans ton exemple, les résultats sont toujours 0 ou -1 avec l'opérateur OrElse...

Citation:

---

Envoyé par Pol63

un modo peut supprimer les 5 posts qui flood à propos de and et andalso ? ^^

---

Mais non, je suis sûr que c'est bénéfique à plein de gens :mrgreen:

Citation:

---

Envoyé par tomlev

Les opérateurs And, Or, & et | ont aussi leur utilité.

D'abord pour un cas d'usage où il 'y a pas d'alternative : les opérations de combinaisons de bits. Par exemple :

---

Attention à ne pas confondre et mélanger les opérateurs arithmétiques logiques et les opérateurs de test. Bien qu'ils s'écrivent et se nomment de la même manière (et qu'ils semblent, à priori, faire des choses similaires) se sont bien des opérateurs différents. Et ici on parle des opérateurs de tests, pas des opérateurs arithmétiques.

re

Citation:

---

Sehnsucht
Quant aux tableaux, je ne suis pas sûr d'avoir compris, si c'est le "problème" d'avoir à écrire 1 là où ça donne 2 éléments ; ce n'est pas près de changer ; il a toujours été précisé que ce qu'on donne sont les bornes des dimensions pas la taille de la dimension (après on aime ou on aime pas mais c'est comme ça et ça représenterait un trop gros breaking change pour que ça change un jour à mon avis)

---

Le probleme que tu ne vois pas c'est que dans vb.net la notion de borne dans la declaration n'existe pas et le codeur doit avoir la "borne dans la tete":
compare ces 2 codes en c# et vb.net qui font le meme travail:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Private arr(2) As Integer 'ce tableau n'as pas la notion de borne que tu invoques ...ressemble a l'array "fortan".... Public Sub New()   For i As Integer = 0 To 2 'ici 2 n'est pas une borne ..d' ou 3 elements...un traquenard!!!   Next   End Sub       private int[] arr = new int[2];//ici 2 est bien une borne public Exemple() { for (int i = 0; i < 2 ; i++) {   } }

---

bon code....

Citation:

---

Envoyé par sevyc64

Attention à ne pas confondre et mélanger les opérateurs arithmétiques logiques et les opérateurs de test. Bien qu'ils s'écrivent et se nomment de la même manière (et qu'ils semblent, à priori, faire des choses similaires) se sont bien des opérateurs différents. Et ici on parle des opérateurs de tests, pas des opérateurs arithmétiques.

---

Je ne suis pas sûr de bien comprendre ce que tu dis... tu veux dire que & et && sont des opérateurs différents (auquel cas on est d'accord), ou que & pour des entiers est un opérateur différent de & pour des booléens ?

C'est bien le même opérateur, il génère d'ailleurs exactement le même code IL...

Code:

---

1 2 3

int i1 = 1; int i2 = 0; int i3 = i1 & i2;

---

Code:

---

1 2 3 4 5 6 7 8

ldc.i4.1 stloc.0 // i1 ldc.i4.0 stloc.1 // i2 ldloc.0 // i1 ldloc.1 // i2 and stloc.2 // i3

---

Code:

---

1 2 3

bool b1 = true; bool b2 = false; bool b3 = b1 & b2;

---

Code:

---

1 2 3 4 5 6 7 8

ldc.i4.1 stloc.0 // b1 ldc.i4.0 stloc.1 // b2 ldloc.0 // b1 ldloc.1 // b2 and stloc.2 // b3

---

Tu remarqueras au passage qu'en IL, les booléens sont traités comme des Int32, donc au final, c'est la même opération qui sera exécutée par le processeur, que tu fasses un "ou" entre deux entiers ou entre deux booléens.

Citation:

---

Envoyé par MABROUKI

re

Citation:

---

Envoyé par Sehnsucht

Quant aux tableaux, je ne suis pas sûr d'avoir compris, si c'est le "problème" d'avoir à écrire 1 là où ça donne 2 éléments ; ce n'est pas près de changer ; il a toujours été précisé que ce qu'on donne sont les bornes des dimensions pas la taille de la dimension (après on aime ou on aime pas mais c'est comme ça et ça représenterait un trop gros breaking change pour que ça change un jour à mon avis)

---

Le probleme que tu ne vois pas c'est que dans vb.net la notion de borne dans la declaration n'existe pas et le codeur doit avoir la "borne dans la tete":
compare ces 2 codes en c# et vb.net qui font le meme travail:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Private arr(2) As Integer 'ce tableau n'as pas la notion de borne que tu invoques ...ressemble a l'array "fortan".... Public Sub New() For i As Integer = 0 To 2 'ici 2 n'est pas une borne ..d' ou 3 elements...un traquenard!!! Next End Sub   private int[] arr = new int[2];//ici 2 est bien une borne public Exemple() { for (int i = 0; i < 2 ; i++) { } }

---

bon code....

---

Tu confonds 2 choses ; une borne et une taille ; une taille c'est le nombre d'éléments ; une borne c'est la position d'un élément spécifique (position de l'élément de départ pour borne de début ; position de l'élément final pour borne de fin)

Dans le code VB.Net tu déclares un tableau de borne maximale valant 2 (donc de taille 3 conséquence de la numération en base 0 des indices) et tu itères sur chacun des indices compris entre 0 et 2 inclus ; soit sur 3 éléments.
Dans le code C# tu déclares un tableau de taille 2 (donc ayant pour indices 0 et 1) et tu itères sur chacun des indices compris entre 0 et 2 (exclus) ; soit 2 éléments.

Personnellement on m'a toujours appris que le nombre d'éléments (la taille :)) d'un ensemble indicé était borne_max - borne_min + 1 (ex: pour savoir combien de chiffres sont compris entre 3 et 7 (inclus) je fais bien 7 - 3 + 1 = 5 et entre 3 et 7 il y a bien 3; 4; 5; 6 et 7 soit 5 chiffres).

Je rappelle à tout hasard (source) qu'à la base ça nous vient de VB6 qui indiçait en base 1 par défaut (et là borne_max ou taille ça revient au même visuellement) mais qui permettait surtout de pouvoir aussi choisir la borne minimale exemple :

Code:

---

Dim arr(3 To 7) As Type

---

ceci donnant un tableau dont le premier élément a pour indice 3 et le dernier élément a pour indice 7 (soit une taille de 5 éléments) [Chose que l'on peut "reproduire" au besoin en .Net avec une des surcharges de Array.CreateInstance]

Au passage à VB.Net il a été décidé par ses concepteurs de ne plus permettre cela et d'indexer tout en numération 0 mais la possibilité d'utiliser cette syntaxe existe toujours (même si elle est peu utilisée 0 étant la seule possibilité valide pour la borne minimale) soit:

Code:

---

Dim arr(0 To 2) As Integer

---

Je donne la source dans la documentation au cas où mais le passage intéressant est celui-ci

Citation:

---

Envoyé par MSDN

You can specify the lower and upper bound of each dimension of an array. To do this, include a boundslist inside the parentheses. For each dimension, the boundslist specifies the upper bound and optionally the lower bound. The lower bound is always zero, whether you specify it or not. Each index can vary from zero through its upper bound value.
(...)
Note that an upper bound represents the highest possible value for the index, not the length of the dimension. The length of the dimension is the upper bound plus one.

---

Cette possibilité a sûrement été conservée pour faciliter la transition à l'époque en limitant les modifications à apporter (dans la majorité des cas un décalage de -borne_min suffisait)
Après, on peut regretter qu'un autre choix n'ait pas été fait à l'époque et ça c'est un argument que je peux comprendre tout comme le fait de ne pas aimer. :)

Citation:

---

Sehnsucht

Dans le code VB.Net tu déclares un tableau de borne maximale valant 2 (donc de taille 3 conséquence de la numération en base 0 des indices) et tu itères sur chacun des indices compris entre 0 et 2 inclus ; soit sur 3 éléments.
Dans le code C# tu déclares un tableau de taille 2 (donc ayant pour indices 0 et 1) et tu itères sur chacun des indices compris entre 0 et 2 (exclus) ; soit 2 éléments.

---

C'est toi qui confonds ces 2 choses,parce qu' en C# on donne une taille alors qu'en vb.net on fournit la "borne superieure maximale" (en plus court Array.GetUpperBound(0) )...
Voici ce que fait observer MSDN fr sur le sujet dans la rubrique Array de visual basic :

Citation:

---

Dim salesAmounts(4, 11, 30) As Double

Étant donné que chaque index varie de 0 à son maximum, notez que chaque dimension de salesAmounts est déclarée avec une valeur inférieure de 1 à la longueur requise pour cette dimension. Notez également que la taille du tableau augmente avec chaque nouvelle dimension. Les trois tailles dans les exemples précédents sont respectivement 31, 372 et 1 860 éléments.

&& l'original :
Note that, because each index varies from 0 to its maximum, each dimension of salesAmounts is declared as one less than the required length for that dimension. Note also that the size of the array increases with each new dimension. The three sizes in the preceding examples are 31, 372, and 1,860 elements respectively

---

Cette expression "longueur requise" est surement requise par un minimun de coherence de l'API.Net et non le mabrouki qui vous parles....
bon code...

Bref ... on va arrêter les frais ; on ne se mettra pas d'accord même la documentation que tu cites va dans mon sens pour moi ("Étant donné que ..." signale pour moi une conséquence, et se résume à "Comme l'index varie de 0 à maximum ; il n'est pas faux de considérer que chaque dimension est déclarée comme longueur - 1")

Tu choisis d'interpréter la documentation ainsi : chaque dimension d'un tableau est définie comme longueur (ou taille) - 1 ; c'est un choix, il est valide (tant que l'index minimum est 0 [ce qui est une obligation heureusement]) et conséquemment tu estimes que c'est une aberration.
Je choisis d’interpréter la documentation ainsi : chaque dimension d'un tableau est définie comme (0 jusqu'à) borne (ou indice) maximal ; c'est un autre choix, il est tout autant valide (même si l'index minimum n'est plus 0 [ce qui n'est pas près d'arriver]) et conséquemment tout s'emboîte et est logique.

Le reste tient lieu de débat plus sémantique qu'autre chose (étant donné qu'une taille (ou longueur) n'est après tout qu'une distance entre 2 bornes (ou vice-versa)).

Je n'interviendrai plus sur cette question et ce n'est de toute façon pas le propos du sujet actuel :).

Cordialement !

Aucune amélioration dans la création de tableaux ou d'ouverture de fichier via VB, dommage.

On reste surtout sur des améliorations de lisibilité, voir de compréhension pour les arrivants, aucun "gros" changement en profondeur en somme.

Citation:

---

Envoyé par Guikingone

Aucune amélioration dans la création de tableaux ou d'ouverture de fichier via VB, dommage.

---

Pour les tableaux, le sujet a été largement débattu ci-dessus.
Pour l'ouverture de fichiers, je ne vois pas ce que tu veux dire : ça dépend du framework, pas du langage, et je ne vois pas grand chose à redire à l'API actuelle... tu voudrais quoi comme amélioration au juste ?

Citation:

---

Envoyé par Guikingone

On reste surtout sur des améliorations de lisibilité, voir de compréhension pour les arrivants, aucun "gros" changement en profondeur en somme.

---

C'est des petits changements, mais il y en a beaucoup... Il faut garder à l'esprit que le gros chantier de cette version, ce n'est pas les fonctionnalités, mais le nouveau compilateur Roslyn. Ils en ont profité pour ajouter plein de petites choses qui étaient attendues depuis longtemps par les développeurs, mais c'est juste du bonus.

Citation:

---

Envoyé par Kropernic

Un reproche qui est souvent fait à VB est d'être trop verbeux.

---

Merci pour la remarque
:merci:

Je confirme, il n'est pas mort car je continue de développer en VB.NET avec WPF et WCF. Ces nouvelles syntaxes qui le rende moins "verbeux" sont les bienvenues. Longue vie au VB !

les inov signalées sont interessantes surtout le ?.
vb est encore trs evolutif et a de bons jours devant

Personnellement, je regrette toujours VB6 qui était beaucoup plus simple d'utilisation. Et s'il m'arrive de programmer en VB.NET, j'ai installé des versions 32bits des systèmes pour pouvoir continuer à utiliser VB6. Je me pose la question de savoir si cette possibilité existera encore sous W10. Il m'arrive encore de devoir booter sous XP afin de pouvoir utiliser certains logiciels ou compilateurs. Il est vrai qu'à 70ans je suis un peu vieux jeu ! De plus, à mon âge, je n'ai plus envie de réinvestir dans tous les nouveaux outils qui ne fonctionnent plus en 64bits (SQL Server, Photoshop, etc.)

Moi aussi ne suis plus si jeune et ai aussi programmé en vb6 qui il est vrai est plus simple mais n'offre pas toutes les possibilités de vb.net. Aussi la migration çà entretient les vieux que nous sommes! vous ne regretterez pas

Pour ma part, j'ai commencé la programmation par le bon vieux C-AINSI/C++ et le java à l'époque... Ce qui ne m'avait pas passionné outre mesure. (En passant plus de temps à comprendre le langage qu'à codé).


Et puis il a fallu que je travaille, et je suis comme vous tombé dans le VB, depuis je ne fais QUE ça.

Il est lisible et puissant (si on s'en sert bien). Du coup, de mon point de vue, ce langage est pratique à la fois pour apprendre et pour développer rapidement. On peut rapidement faire des choses toute bête, et petit à petit apprendre les subtilités.


La dernière chose que j'ai envie, c'est de retrouver les accolades pour faire un If, les pointeurs, les déclarations de pointeurs de variables, des pointeurs de pointeur, les & les *.... et mettre un point virgule à chaque ligne... Gérer la taille des tableaux (bien que je crois que l'allocation dynamique de mémoire ne se fait plus partie du .NET)

Puis pour déclarer une variable... en commençant par son type, j'ai jamais compris... C'est pour aider le pauvre compilateur tout ça en fait... Il arrive pas à mettre les choses dans l'ordre lol.

Comme pour les points-virgules, en fait il faut lui dire quand la ligne s'arrête, sinon il est bête il prends tout ton code et le lit comme un fichier texte ! Tout comme le type void d'une fonction... qui sert à dire qu'on ne retourne rien.... 8O

En fait le C# c'est le développeur qui assiste la machine, le VB l'inverse ! ;)
(Je suis de partie pris, vous l'aurez compris!)

Pourquoi faire simple quand on peut faire compliqué ?
Depuis VB6 les "améliorations" de VB ne sont que des complications - avis tout à fait perso bien sur.

j'utilise beaucoup le Basic pour la programmation de micro-contrôleurs avec le Bascom-Basic sur µ-contrôleur AVR de chez Atmel pour faire des automates de plus en plus complexe.
La structure des programmes est claire, le compilateur rapide. si on bloque on écrit qq lignes en assembleur, rien que pour titiller les registres..:lol:
Pour les transfert de données j'utilise VBA qui jusqu'à 2010 était quasiment Du VB6
Avec Basic4android on se comprend, c'est très proche.

Mais l'usine à gaz Studio de Microsoft me dépasse... et on appelle cela un langage pour débutant ?
Atmel a sorti un "Studio" universel pour ces µ-contrôleurs, même genre d'usine à gaz.

A quand un retour à la simplicité d'un VB6 ?
Ne tuons pas Basic qui n'est pas un langage pour les nuls.

Citation:

---

Envoyé par candide02

Pourquoi faire simple quand on peut faire compliqué ?
Depuis VB6 les "améliorations" de VB ne sont que des complications - avis tout à fait perso bien sur.

---

Effectivement, VB.NET est plus complexe que ne l'était VB6. Mais il est aussi et surtout beaucoup plus puissant... VB6 était un langage basé sur des objets, mais pas réellement orienté objet : par exemple, il n'y avait pas de notion d'héritage, qui est quand même la base des langages OO... VB6 est très bien pour apprendre à coder (c'est d'ailleurs un des premiers langages que j'ai utilisés) et faire de petites applications simples. Ses proches cousins VBA et VBScript sont tout à fait adaptés pour faire des macros, de l'automatisation de tâches bureautique et du scripting système. Mais pour développer de vraies applications complexes, VB6/VBA/VBS sont vraiment trop limités...

Citation:

---

Envoyé par candide02

Mais l'usine à gaz Studio de Microsoft me dépasse... et on appelle cela un langage pour débutant ?

---

Mais c'est toi qui appelles ça un langage pour débutant... VB.NET n'est pas plus un langage pour débutant que C# (d'ailleurs les fonctionnalités sont quasiment les mêmes, ainsi que tous les concepts liés à la plateforme .NET). C'est une idée largement répandue que VB.NET est un langage "facile" (peut-être parce que VB6 l'était), et du coup les débutants se dirigent souvent vers ce langage. Mais c'est une idée fausse... Ce qui est malheureux à mon sens, c'est que beaucoup de choses dans la syntaxe de VB.NET ne sont là que pour le faire paraitre plus simple, en masquant certaines subtilités qui sont pourtant essentielles à comprendre. Du coup, quand on tombe sur un bug lié aux limites de ces "simplifications", on sait plus quoi faire parce qu'on ne comprend pas vraiment le fonctionnement du langage. Je pense par exemple aux instances par défaut de Form dans les applications Windows Forms ; c'est probablement la "feature" la plus aberrante de VB.NET, et elle n'existe que pour éviter aux développeurs d'avoir à comprendre des concepts de POO...

Quant au fait que Visual Studio soit une usine à gaz : c'est pas complètement faux, mais ça s'explique et se compense par le fait que c'est un IDE extrêmement riche et complet. Comme je le disais dans un autre topic, s'il y a bien une application qui me retiens sous Windows, c'est bien Visual Studio. Evidemment l'IDE de VB6 était beaucoup plus léger, mais il était aussi beaucoup moins riche en fonctionnalités... si je devais recommencer à l'utiliser, j'aurais l'impression de revenir à l'âge de pierre.

Citation:

---

Envoyé par candide02

A quand un retour à la simplicité d'un VB6 ?

---

C'est pas demain la veille. Du point de vue de Microsoft, VB6 est mort et enterré. Il y a plein de gens qui continuent à l'utiliser, mais il n'évolue plus depuis au moins 15 ans. VB.NET, pendant ce temps, s'améliore, mais il ne va pas devenir plus "simple".

Citation:

---

Envoyé par candide02

Ne tuons pas Basic qui n'est pas un langage pour les nuls.

---

Il faudrait savoir... d'abord tu dis que c'est supposé être un langage pour débutant, et ensuite tu dis que ce n'est pas un langage pour les nuls ;) (bon, OK, débutant n'est pas synonyme de nul, mais quand on débute, on commence forcément par être nul...)
VB6 est un peu un langage "pour les nuls" (ce qui en fait ne veut pas dire grand chose), ou du moins un langage pour ceux qui n'ont pas envie de se prendre la tête avec des concepts avancés. VB.NET est un langage avancé (bien qu'un peu bancal à mon avis), qui effectivement n'est pas "pour les nuls", puisqu'il nécessite une bonne compréhension de la POO et de la plateforme .NET.

Tu as tout à fait raison.

Je donne des cours d'informatique à des "Mme Michu", je voudrais ouvrir un atelier programmation pour des ado. Quels langages conseillerais-tu ? sachant que comme beaucoup de Basic-addict, je ne supporte pas le C c'est épidermique ! Peut-être Python ?

Merci de tes conseils.
JP

Citation:

---

Envoyé par candide02

Je donne des cours d'informatique à des "Mme Michu", je voudrais ouvrir un atelier programmation pour des ado. Quels langages conseillerais-tu ? sachant que comme beaucoup de Basic-addict, je ne supporte pas le C c'est épidermique ! Peut-être Python ?

---

Le C, de toute façon je ne le recommanderais pas pour une initiation, c'est un trop peu ardu quand on a jamais codé... Mais une fois que les concepts de base de la programmation sont maitrisés, je pense que c'est une bonne idée d'apprendre le C pour mieux comprendre comment fonctionne l'ordinateur (gestion de la mémoire, pointeurs...)

Python, pourquoi pas. C'est un des langages les plus simples au niveau de la syntaxe, et on peut facilement démarrer de zéro, il n'y a pas vraiment de pré-requis.

Après, sur ce sujet, il y a autant d'avis que de personnes... Regarde cette discussion pour d'autres avis.

prend des langages à la mode ça permet d'avoir plus d'attentions de la part des élèves.
après je conseillerai de prendre celui avec lequel VOUS etes le plus a l'aise.
il faut évité de demander "Quel langage conseillez vous !" puisque personne n'est jamais d'accord, et pour le prouver il n'y qu'a regarder le nombre de poste sur ce sujet.


Je donne tout de même mon avis puisque la question est posé.
Alors tout dépend des envies de réalisation et de l'envi d'apprentissage
pour ma part je conseillerais
- le C# (le meilleur :mrgreen:) : il donne un excellent IDE, un framework complet et pas surcharger. Mais utilisable que sur windob pour le moment
- le java : permet de développer sur tout type de plateforme, ce qui un gros avantage dans notre période de mobile, il possède aussi un excellent framework
mais il faut faire attention a la version utilisé et au prédicate
- le C++ : excellent IDE (Qt5), excellent pour apprendre, une fois que l'on maitrise ce langage, les autres ne pose plus de problème
voila ce qui est de mon avis pour la POO mais il ne fait pas oublié que le SQL est obligatoire

Cordialement