PureBasic

Je ne sais pas si cela a déjà était relevé, mais l’analyseur syntaxique autorise des expressions et des opérations assez étranges !

Code : Tout sélectionner

a = b = 10
c + d = 10

Debug a
Debug b
Debug c
Debug d

C'est clûr !

Autres situations étonnantes :

Code : Tout sélectionner

a = 1
b = 20

resultat= (a < b)

If (a < b)
  Debug resultat
EndIf

; ------------------------
Debug ""
; ------------------------
a = 1
b = 20
limite = 100

Debug a < b
Debug (a + 10) >= limite
Debug a = b
Debug b <> limite

On peut voir ici que le résultat d’une expression impliquant un opérateur relationnel, ne fonctionne correctement quà l'interieur d'une instruction If.

Bien que trés limitant, on peut penser que cela soit voulu, mais j’en doute fort puisque dans l’exemple, l’expression a < b donne 20, ce qui ne veut rien dire.

Ce problème a déjà était relevé sur le forum anglais.
J’ai d’ailleurs retrouvé leur post

Une astuce pour contourner le probleme (hors instruction If) consiste à ajouter un opérateur logique à l’expression désirée :

Code : Tout sélectionner

a = 1 
b = 20 
limite = 100 

Debug a < b And #True
Debug (a + 10) >= limite And #True
Debug a = b And #True
Debug b <> limite And #True

Il faut tout de même reconnaître que si l'opération relationnelle:

Code : Tout sélectionner

a < b

a un sens, en revanche l'opération suivante est ambiguë :

Code : Tout sélectionner

a = b

S'agit-il d'une opération d'affectation ou d'une opération relationnelle ?
Or,cette ambiguïté est levée du moment que l'on utilise un opérateur logique (And/Or) ou une instruction conditionnelle (If/EndIf, While/Wend, Repeat/Until) par exemple.

Donc la situation sur ce point me parait nominale : comme PureBasic possède cette ambiguïté, il n'autorise pas de tels opérations isolées. Sa réaction l'est moins par contre car il devrait afficher un message d'erreur plutôt que de laisser l'opération se faire.

On comprend mieux alors le choix du C de prendre "==" comme opérateur d'égalité.

Une solution possible afin de supprimer l'équivoque, sans pour autant changer l'opérateur, serait d'encadrer l'opération par des parenthèses lorsqu'il y a ambiguïté, ainsi :

L'affectation reste : a = b
L'égalité devient : (a = b)

Mais quid de l'expression suivante ?

Code : Tout sélectionner

a = b = c

Dans l'état actuel des opérations d'affection autorisées dans PureBasic (pas d'affectations multiples),
le deuxième « = » est forcement une égalité
Reste à se donner une règle pour le premier « = » : conserver l'affectation par défaut par exemple ?
Dans ce cas, a = b = c est équivalent à a = (b = c)
Dans l'expression (a = b) = c, les deux opérateurs « = » sont des égalités

Imaginons maintenant que PureBasic autorise les affectations multiples
a = b = c, les deux « = » sont foncement des affectations
dans les expressions suivantes
a = (b = c), le premier « = » est une affectation, le deuxième une égalité
(a = b) = c, les deux sont des égalités.

D'autres exemples d'expressions :
c= a< b se comprend comme une affectation du résultat (a < b) dans c car équivalent à c = (a < b)
(c = a) < b correspond à deux opération relationnelles successives : d'abord l'égalité puis l'inférieur
a < b = c, « = » est l'opérateur égalité (pas besoin de parenthèses)

Ca commence a etre un peut imbuvable tous cela, et bien que peu de personnes soient amenées à travailler de telles expressions « isolées », cette histoire mérite d’etre plus claire, non ?

A+

PureBasic

Des expressions assez étranges !

Des expressions assez étranges !