merci bien pour ta si gentille appréciation, ça fait toujours plaisir !
(n'est-ce pas ? 
) ; j'ose espérer que mes explications vaseuses plairont à d'autres lecteurs de cette conversation, même si ça n'est pas ton cas ; comme actuellement il y a 157 740 autres membres, ça me laisse quand même un peu d'espoir ! 
a) mes explications ne sont
PAS vaseuses, bien au contraire ! je sais parfaitement que mes explications sont
très claires et même
limpides pour quiconque comprend bien le français ; il suffit de les lire
attentivement pour comprendre
en quoi l'évaluation de certaines parties du test est
complètement inutile ; c'est d'ailleurs la raison pour laquelle
Philippe Kahn, le PDG de l'ex-société Borland, avait décidé d'implémenter
l'évaluation prédictive des tests dans son langage
Turbo Pascal, alors même que la compilation était pourtant extrêmement rapide, ainsi que l'exécution ; ça aurait été assurément une excellente chose si Microsoft l'avait imité sur ce point !
(c'est sans doute car Crosoft a moins le souci de la satisfaction de sa clientèle que l'avait Borland ! )
b) je reconnais quand même que c'est par simple
« purisme », de la même façon que je mets
(quasiment) toujours une sub appelée
avant son appel : c'est une habitude que j'avais prise quand j'utilisais une des premières versions de
Turbo Assembleur ou de
Turbo Pascal : la phase de compilation bloquait s'il y avait appel d'une sub ou d'une fonction située en aval de son lieu d'appel ; c'est seulement ensuite que sont apparues des versions qui savaient effectuer la résolution des adresses aval ; plus d'infos sur les compilateurs ici :
lien Wikipédia ; dont la différence entre un compilateur simple passe (monopasse) et un compilateur multi passe ; en général, y'a une passe en avant qui « garde en mémoire » la trace des adresses qui n'ont pas pu être résolues lors de cette 1ère passe, qui est suivie d'une seconde passe en arrière, pour résoudre effectivement les adresses non résolues lors de la 1ère passe.
c) « Chez moi 1,1 millionième de seconde !!! » : c'est effectivement ultra-rapide !!! n'empêche que ça évalue quand même
bêtement et
inutilement des parties de tests, puisqu'on sait
d'avance que si Target.Column est
différent de
37, le test sera
VRAI dans
tous les cas (peu importe la suite du test), car c'est l'opérateur
Or qui est utilisé ➯ l'évaluation du test peut stopper
aussitôt,
sans avoir à évaluer
la suite du test qui est
Or Target.Row > 441 Or (Target.Row - 7) Mod 62 (soit 2 évaluations complètement inutiles) ; CQFD.
et je t'assure que pour celui qui veut concevoir un compilateur vraiment performant, faire l'évaluation complète d'un test est une incongruité flagrante, quels que soient le temps de compilation et le temps d'exécution !
donc avec cette seule ligne de test de job75 :
