Bonjour,
Comme j'ai dit, je suis plus familier avec VB qu'avec C#. Je vais donc parler pour VB (VB.net, VB6 et VBA, c'est semblable pour les 3)
À l'origine BASIC (Beginners All Purpose Symbolic Instruction Code) a été conçu comme un langage devant être utilisé dans l'apprentissage plus vaste du Fortran. Pour peu que je puisse comprendre la conversion implicite permettait d'arriver à un programme fonctionnel sans trop se préoccuper des types de données. Cela a fait du BASIC un langage extrêmement souple et léger qui pouvait fonctionner dans des PC avec aussi peu que 8 k (sic) de mémoire. (Moyennant quelques sacrifices comme une cassette audio 4 pistes comme mémoire de masse, sans disque dur, un écran strictement texte au début et en noir (vert) et blanc.
Quand Microsoft et d'autres ont décidé d'intégrer un logiciel de programmation dans les PC naissants, BASIC s'est avéré le choix le plus logique et s'est largement imposé. Mais la conversion implicite a été maintenue.
Par exemple dans tes deux lignes suivantes:
1
2
| resultat = (e + f / 2).ToString(); // On convertit un int en string pour afficher le texte
Console.WriteLine("La moyenne est:" + resultat); |
Tu as converti ton résultat d'un type mathématique à un type String.
Dans un programme VB.net si tu as désactivé les conversions explicites, une seule ligne (sans le ";" ) suffit
Console.WriteLine("La moyenne est:" + resultat)
Dans ce cas, que ton calcul donne un résultat mathématique n'a pas grande importance. VB va prendre ton résultat mathématique et le convertir en texte, sans poser de question. Il va se dire ce nombre-là est supposé être en texte, on en fait un texte. Si c'était juste cela, cela ne serait pas vraiment problématique.
Un autre cas où la conversion implicite va fonctionner assez bien (Très semblable en VBA, si jamais tu dois l'utiliser avec Microsoft Office)
en VB.net
1
2
3
4
5
6
7
| Sub ImpliciteVBnet()
dim résultat as Integer 'résultat est un entier
textbox1.text = 3
Textbox2.text =9
résultat = textbox1.text * textbox2.text
messagebox.show (résultat)
End sub |
en VBA
1
2
3
4
5
6
7
| Sub ImpliciteVBA()
dim résultat as Integer 'résultat est un entier
textbox1.text = 3
Textbox2.text =9
résultat = textbox1.text * textbox2.text
msgbox(résultat)
End sub |
Même si 3 et 9 sont en théorie du texte, la conversion implicite va en faire deux entiers pour que résultat soit entier, puis résultat, toujours grâce à la conversion implicite va devenir un texte pour pouvoir être gobé et affiché par la messageBox.
Mais là où la conversion peut devenir une vraie peste, c'est dans des choses du genre.
1
2
3
4
5
6
7
| Sub ImpliciteVBnet2()
dim résultat as single 'résultat est un nombre en virgule flottante en précision simple
dim a as Integer 'a est un entier
dim b as long 'b est un entier long
c= a+b
résultat = c/3,14
End sub |
Dans ce cas, pour avoir C, il est impossible de faire l'addition sans convertir l'un ou l'autre des nombres. La conversion implicite va choisir le type de donnée unique qui peut inclure les autres types de données et les convertir sans prévenir dans le type unique. Là, ce n'est pas si mal, dépendant de la valeur de a et b on va avoir deux integer ou deux long et c va être Integer ou Long, selon le résultat.
Mais là, le résultat final doit être en virgule flottante et précision simple et la surprise peut être totale. En premier lieu, la conversion implicite va regarder la valeur de c. Si c dépasse la valeur limite d'un nombre en Single, c va être converti en Double et 3.14 aussi. Mais comme résultat doit être Single, tu vas avoir un résultat en Single, si le résultat est plus petit que la valeur maximale du type single. Sinon, tu vas avoir un beau message d'erreur. Et quelqu'un qui n'est pas familier avec la conversion implicite pourrait chercher longtemps.
C'est encore pire en VBA (ou VB6). En VB6-VBA un nombre en Integer ne peut pas dépasser 32768 pou être inférieur à -32767. Le type Long peut atteindre quelque chose dans les 2 700 000, si mes souvenirs sont exacts. Cala fait que des choses dans ce genre-là sont encore plus dangereuses qu'en VB.net
1
2
3
4
5
6
7
8
9
10
| Sub ImpliciteVBA2()
dim résultat as single 'résultat est un nombre en virgule flottante en précision simple
dim a as Integer 'a est un entier
dim b as long 'b est un entier long
dim c as integer
a= 32500
b= 8000
c= a+b
résultat = c/3,14
End sub |
Là, avec c devant être en Integer, l'addition devient carrément impossible, parce que la conversion implicite devient incapable de convertir un résultat en type Long en type integer, parce l'additition dépasse 32768. La prime, un beau plantage. Et puis, on n'a pas encore parlé des variables qui sont passées en paramètres ou des variables publiques.
Même que la conversion implicite permet des acrobaties du genre:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| Sub ImpliciteVBA3()
dim résultat as single 'résultat est un nombre en virgule flottante en précision simple
dim a as String 'a est un texte
dim b as Integer 'b est un entier
a= "2500"
b= 8000
c= a+b
résultat = c/3,14
End sub
Sub ImpliciteVBA4()
dim résultat as single 'résultat est un nombre en virgule flottante en précision simple
dim a as String 'a est un texte
dim b as Integer 'b est un entier
a= "2500"
b=1
c= a*b
résultat = c/3,14
End sub |
Si je me fie à cette discussion le C n'autorise pas la conversion implicite. Cela oblige à prévoir et effectuer chaque conversion explicitement, ce qui oblige à prévoir les résultats et permet de dépister plus facilement les erreurs. Avec la conversion implicite, les temps de développement sont possiblement plus courts, mais la conversion implicite mal maîtrisée peut être source d'erreurs.
Mais VB permet heureusement de rendre obligatoire la déclaration explicite
Je suis faché avec les conversions en C#
Répondre avec citation
Envoyé par juju742
.
Partager