WD12 - opérateur logiques ET, _ET_, OU, _OU_

Le
I.G.LOG
Bonjour,

Je viens de découvrir dans la doc les opérateurs _ET_ et _OU_.

_ET_: "Multiplication logique. Les conditions composées de _ET_ sont
évaluées de manière optimisée. Si la première partie de l'expression est
fausse, la suite de l'expression n'est pas évaluée".

Contrairement au ET pour lequel les deux parties sont évaluées. Mais dans
quel cas peut on avoir besoin que cet opérateur évalue les deux expressions
??? Et si ce cas n'existe pas, pourquoi ne pas avoir optimisé le ET tout
simplement sans ajouter un nouvel opérateur _ET_ ?

Idem pour le _OU_
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Tanguy
Le #21078901
Ce n'est pas juste une optimisation,

exemple simple :

bDebug est boolean

SI bDebug _ET_ GetErreurDonnee(sPrograme) ALORS
...
FIN

Il peut etre important de n'executer la fonction
que si bDebug est à Vrai (interface inexistante par exemple)

Dans d'autres cas, il peut etre utile d'executer des fonctions

SI TableAjouteLigne(xxx) ET ListeAjoute(xxxx) ALORS
...
FIN

Ils ne peuvent pas changer le comportement des opérations
logiques sans risquer d'avoir des problemes de migration...

Enfin bon, j'ai decouvert ca dans une LST ou sur le blog du ST
il y a quelques années... et c'est bien utile...

Je crois que ca date de WD10 ou 11

--
Contact : http://tanguy.ath.cx
I.G.LOG
Le #21078921
>
Dans d'autres cas, il peut etre utile d'executer des fonctions

SI TableAjouteLigne(xxx) ET ListeAjoute(xxxx) ALORS
...
FIN




effectivement, c'est un cas où on doit évaluer les deux expressions.. cas
auquel je n'avais pas pensé !
merci pour la réponse, je vais vérifier mon code, car j'ai transformé tous
les ET en _ET_ et les OU en _OU_ ...
Daniel
Le #21079031
Le 29/01/2010 07:20, Tanguy a écrit :
Ce n'est pas juste une optimisation,

exemple simple :

bDebug est boolean

SI bDebug _ET_ GetErreurDonnee(sPrograme) ALORS
...
FIN

Il peut etre important de n'executer la fonction
que si bDebug est à Vrai (interface inexistante par exemple)

Dans d'autres cas, il peut etre utile d'executer des fonctions

SI TableAjouteLigne(xxx) ET ListeAjoute(xxxx) ALORS
...
FIN

Ils ne peuvent pas changer le comportement des opérations
logiques sans risquer d'avoir des problemes de migration...

Enfin bon, j'ai decouvert ca dans une LST ou sur le blog du ST
il y a quelques années... et c'est bien utile...

Je crois que ca date de WD10 ou 11




W10

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Daireaux Jean-Baptiste
Le #21080061
Tanguy a écrit :
Ce n'est pas juste une optimisation,

exemple simple :

bDebug est boolean

SI bDebug _ET_ GetErreurDonnee(sPrograme) ALORS
...
FIN

Il peut etre important de n'executer la fonction
que si bDebug est à Vrai (interface inexistante par exemple)

Dans d'autres cas, il peut etre utile d'executer des fonctions

SI TableAjouteLigne(xxx) ET ListeAjoute(xxxx) ALORS
...
FIN

Ils ne peuvent pas changer le comportement des opérations
logiques sans risquer d'avoir des problemes de migration...

Enfin bon, j'ai decouvert ca dans une LST ou sur le blog du ST
il y a quelques années... et c'est bien utile...

Je crois que ca date de WD10 ou 11





Nous faisons face à une spécificité de windev : la plupart des langages
de développement que je connais, n'évaluent pas la deuxième clause du
'ET' quand la première est fausse.

C'est une anomalie, de mon avis, que j'ai découvert avec WD55. Je n'ai
jamais rencontré un cas où l'évaluation de la seconde clause avait un
sens quand la première était fausse. De plus cela augmente le risque de
bogue avec du code comme :

SI i>0 ET Table.truc[i]<>"" alors
...
FIN

En java, c, c++, pascal, Askel, python, les lignes ci-dessus ne plantent
pas si i<0.

De plus, en logique, si vous donnez de l'importance à l'évaluation de la
seconde clause quelque-soit le résultat d'évaluation de la première,
cela signifie que vous devriez faire exécuter la seconde clause avant
même de commencer le 'SI'.

Pour l'exemple indiqué, si le 'ListeAjoute(xxx)' doit être exécuté
quelque soit le résultat du 'TableAjouteLigne(xxx)' alors moi
personnellement, j'écrirai

b=ListeAjoute(xxx)
SI TableAjouteLigne(XXX)>0 alors
SI b alors

FIN
FIN

c'est un peu plus long mais cela se révèle plus rapide à comprendre en
maintenance et c'est plus simple au déboguage.

J.B.D.
Firetox
Le #21080051
Bonjour,


Nous faisons face à une spécificité de windev : la plupart des langages de
développement que je connais, n'évaluent pas la deuxième clause du 'ET'
quand la première est fausse.



oui entierement d'accord avec toi de meme que pour les procedures ou
fonction windev passe par defaut les parametres par adresse et non par
valeur comme tous les autre s langage dans le fonctionnement en c ou autre
il faut specifié par le & qu'on passe le parametre par valeur or windev fait
le contraire il faut mettre les ( ) pour specifier qu'on passe le parametre
par valeur

de ce fait c'est le choix de l'editeur comme nous le faisons dans nos
programme
ensuite il est vrai que cela soit sur les parametres ou les condtions et les
_ET_ _A_ _OU il faut bien que par securite on ne change pas le
fonctionnement intial pour eviter les regressions et donc une nouvelle
ecriture pour faire quelque chose de speciale ou nouvelle fonction

je vous l'accorde cela n'est pas "logique" au sens des autre langage mais
combien d'entre vous auraient crié au scandal si jamais il avait modifié la
fonction initial et apporté des regression dans vos logiciel ?

Bon dev
@+
Firetox
Le #21080041
vous aurez corrigé de vous meme

oui entierement d'accord avec toi de meme que pour les procedures ou
fonction windev passe par defaut les parametres par adresse et non par
valeur comme tous les autre s langage dans le fonctionnement en c ou autre
il faut specifié par le & qu'on passe le parametre par adresse or windev
fait
le contraire il faut mettre les ( ) pour specifier qu'on passe le parametre
par valeur

Bon dev
@+
Publicité
Poster une réponse
Anonyme