Discussion :

[LeonCosnyd]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SI iTaValeur DANS (iVal1,iVal2) ALORS
//Ne rien faire 
 SINON
 li_compteur++
FIN

Personnellement je déteste voir des conditions avec aucun traitement dedans. Je trouve que cela créé des espaces vides en plus rendre le code un peu moins lisible.

[michel.souris]

Personnellement je déteste voir des conditions avec aucun traitement dedans. Je trouve que cela créé des espaces vides en plus rendre le code un peu moins lisible.

Entièrement d'accord... même si c'est juste de l’esthétique...

D'autant plus que je ne suis pas convaincu de ce qui est avancé...

IF NOT x _IN_ sortira dès qu'une valeur sera trouvée.... je ne vois pas où est l'optimisation avec IF x _IN_ (xxxxx) THEN ELSE.... pour moi faire Expression = Vrai ou Expression = Faux, c'est la même chose. C'est un test.
Après tout cela est théorique et nous sommes en train d'imaginer comment le "compilateur" PCSoft interprète tout ça...

Je ne sais pas réellement comment la machine virtuelle WD traite ça.... Y-a-t'il un expert C++ dans la salle ?

[dsr57]

Bonjour

IF NOT x _IN_ sortira dès qu'une valeur sera trouvée.... je ne vois pas où est l'optimisation avec IF x _IN_ (xxxxx) THEN ELSE....

L'optimisation est sur le faite que le NOT est appelé après le test de _IN_ et donc entraine deux tests, je suis d'accord que je fais une forte hypothèse sur l'interprétation du compilateur. Ce qui m'a amené à rédiger une telle réponse est la lecture d'un article qui parlait des optimisations de programme dans un langage comme c# ou PHP, alors je me dis que si un tel langage réagis comme cela je ne vois pas pourquoi PC-Soft ferais mieux, malheureusement je ne trouve plus cette source...

Après tout cela est théorique et nous sommes en train d'imaginer comment le "compilateur" PCSoft interprète tout ça...

Je suis d'accord

Bon dev à tous

[yoshi570]

La partie optimisation dépend fortement (pour ne pas dire exclusivement) du compilateur.
Certes, certaines syntaxes seront plus facilement 'optimisable'.

Ensuite, vous parlez tous de performance selon tel ou tel syntaxe.
Ma question est donc la suivante: combien de fois avez-vous écrit/réécrit du code pour optimiser du code ?

Certainement plusieurs fois, mais lié a des fonctions avancées.
Et probablement très peu (voir aucune) fois, en jouant sur les SI et autre test simple

En tout cas, c'est le cas pour moi.
Si le traitement et lourd et long => Thread, TachesPlanifiée, etc... pour pas embêter l'utilisateur
Si c'est long et qu'il faut le faire souvent, penser a changer de philosophie/ Traitement planifié, vue matérialisé etc...
Si malgré tout, il vous faut désespérément de la vitesse instantanée: penser a utiliser un autre language (il y plein de techniques)

Pour moi, jamais un _X_ m'as fait de miracle. Il faut plutôt pensez autrement.

Ce que je retient de la puissance des X ou _X_ et le fait de déterminer si les évaluations suivantes seront faits ou non.
Je m'en sert, par exemple, pour m'assurer que l'évaluation suivante de provoquera pas d'erreur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IF Length(sCRead) >= 3 _AND_ sCRead[[3]] = Caract(2) THEN

A savoir, si je ne m'abuse, en C++ le standard est _X_
Si je reprend le cas de LeonCosnyd et du sont formulaire, cela serait plus long a écrire en C++
Donc merci d'avoir une syntaxe simple pour pouvoir choisir le comportement que l'on veut !

[michel.souris]

Un _OU_ ou un _ET_ peut faire des miracles...

Imaginons le test suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
IF bSimpleBooleen _AND_ FonctionTresLongue() THEN
     ....
END

Si bSimpleBooleen est faux le test ci-dessus sera beaucoup long à réaliser qu'avec la syntaxe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
IF bSimpleBooleen AND FonctionTresLongue() THEN
     ....
END

Pïre encore imaginons le test suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
IF ChampExiste(MonChamp) _AND_ TestSurLaValeurOuAutre(MonChamp) THEN
     ....
END

Avec la syntaxe ci-dessus, ça passe. Avec la syntaxe ci-dessous ça plante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
IF ChampExiste(MonChamp) AND TestSurLaValeurOuAutre(MonChamp) THEN
     ....
END

D'où l'intérêt de connaitre cette subtilité...

Et oui en C++ (et dans la plupart des langages) le comportement standard est _AND_, _OR_ et cie.
Pour rejoindre ce que dsr57, j'ai effectivement toujours entendu "Ne fais pas de NOT IN"...

EDIT : je relis le message juste au dessus et encore une fois je ne fais que redire ce qui est dis... sorry, c'est le matin...