Decompilateur VB6

[automne]

C'est peut-être pas une question de compilation / interpretation mais peut-être une question d'optimisation de code. VB est un langage de haut niveau qui utilise des "briques" de haut niveau. J'entend par "briques" l'ensemble des fonctionnalités du runtime VB + les fonctionnalités haut niveau du langage (comme l'utilisation du signe '+' à la fois pour faire des additions ou pour faire des concaténations de chaines de caractères.

 

Ca veut dire que les briques en question doivent pouvoir s'adapter à des utilisations multiples qui ont, de temps à autres, peu de choses à voir les une avec les autres. Ca entraine beaucoup de génération de code pour soutenir tous les cas possibles et comme ces briques sont fixes (précompilées pour gagner du temps à la compilation de chaque application et parce que petitmou ne veut pas qu'on voit le code qu'il développe donc il ne fournit pas les sources), pas d'optimisation à l'intérieure des briques à la compilation.

 

Pour reprendre l'exemple du '+', ca veut dire qu'il y a deja une fonction précompilée qui sera ajoutée à l'édition des liens et qui fait tout ce que fait le '+' en fonction des paramètres en entrée. Donc la fonction prend les 2 opérandes, vérifie leur type et si ce sont tous 2 des numériques, elle les additionne, si on a au moins 1 chaine de caractère, elle les concatène.

 

Alors vous allez me dire, en Java ou en C++ (avec les surcharges d'opérateurs), on devrait avoir la meme chose. Mais NON, et pour 1 seule raison : VB est un langage faiblement typé. Ce qui fait qu'à la compilation, on ne sait pas totalement ce que les variables seront. D'où la détermination pendant l'execution de l'application. Dans le cas du Java ou du C++, langages fortement typés, la nature des opérandes est connue avant la compilation (meme si pour Java c'est une compilation en byte-code) et c'est donc pendant la compilation (et meme pendant la précompilation il me semble en C++) que la bonne fonction sera utilisée car on a 1 fonction spécialisée pour chaque cas particulier au contraire du VB.

 

Ca explique le problème de Leneuf22. Le '=' permet à la fois d'affecter et de comparer, et il permet de faire ca sur des nombres, des objets, des chaines, etc alors que le strcomp ne sait que comparer des chaines. Fonction spécialisée et donc déroulant beaucoup moins de code pour arriver au meme résultat.

 

Voilà mes 2 cents sur le sujet. J'espère avoir pu eclairer votre lanterne.

 

Automne

[leneuf22]

Ca explique le problème de Leneuf22. Le '=' permet à la fois d'affecter et de comparer, et il permet de faire ca sur des nombres, des objets, des chaines, etc alors que le strcomp ne sait que comparer des chaines. Fonction spécialisée et donc déroulant beaucoup moins de code pour arriver au meme résultat.

D'accord... donc si on considère ces "briques", elles ne sont donc pas dédiées à quelque chose en particulier... donc si VB est bien organisé comme tu le dis, il y aurait une brique "=".

Si son rôle n'est pas clairement déterminé à la compilation, il l'est forcément à l'exécution... ce qui entraîne une interprétation dans le choix du comportement à adopter pour la brique !

On peut donc dire qu'un programme VB6 compilé en code natif est en fait du code natif qui "s'interprète" ?

 

En tous cas, on pourrait penser que le compilateur serait assez intelligent pour ne pas faire de différence entre "" et vbNullString... qui sont des constantes de type string !

[automne]

En tous cas, on pourrait penser que le compilateur serait assez intelligent pour ne pas faire de différence entre "" et vbNullString... qui sont des constantes de type string !

Heuu faut pas trop en demander à Petimou non plus

 

Automne