Discussion :

[Stef_D]

Salut,

Je développe depuis un peu plus de 3 ans en Delphi (je ne connais donc pas tout) et plusieurs fois je me suis fais avoir avec les fameuses fonctions qui retournent un booléen.
Je m'explique, imaginons la fonction suivante :

Code :

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

1
2
3
4
5
6
7
function DoAllTasks: boolean;
begin
  result:= true;
  result:= result and DoTask1;
  result:= result and DoTask2;
  ...
end;

Je pense que vous voyez où je veux en venir...
Le but de ma fonction est donc de faire tout les traitements (qui influent de manière "globale" sur l'application), elle retourne vrai si tout s'est déroulé correctement, faux sinon.
Mais voilà, ainsi écrite, la fonction peut ne pas fonctionner correctement car si DoTask1 retourne false, alors Delphi va "optimiser" le traitement.
Cette optimisation sur les booléens est désactivable via un $define (enfin je me comprends ^^) mais j'en ai besoin pour les conditions de ce genre : if ((obj <> nil) and (obj.isDone))...
Ce qui me chagrine c'est que pour faire fonctionner la fonction malgré tout, on peut faire ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
function DoAllTasks: boolean;
var
  b: boolean;
begin
  result:= true;
  b:= DoTask1;
  result:= result and b;
  b:= DoTask2;
  result:= result and b;
  ...
end;

Et là ça marche !
Je trouve ça illogique car d'un point de vue algorithmique le code est absolument identique dans les 2 cas ! Delphi devrait donc se comporter de la même manière.
De mon point de vue, le premier cas devrait permettre l'éxécution de toutes les fonctions, si celles-ci modifient "globalement" le programme.
Le langage C/C++ prendre en compte cette donnée. Selon le compilateur, il va essayer d'analyser le comportement de la fonction appelée et si elle ne fait qu'un traitement local, il va l'ignorer sinon il l'éxécute pour garder la cohérence dans le traitement global du programme.
Il existe même un mot clé pour déterminer si une fonction fait un traitement local uniquement pour aider le compilateur à optimiser son code car dans le doute, il assume un traitement global.
Peut-être existe-t-il un mot clé du même genre en Delphi pour lui indiquer d'éxécuter la fonction quoiqu'il arrive ? Malgré tout je ne trouve pas ça logique, par sécurité il devrait avoir le comportement contraire par défaut.
La syntaxe "pascal" ne permet pas de faire une affectation et une condition à la fois, y'a donc uniquement ce cas avec les fonctions qui pose problème... à l'inverse de la syntaxe "C" qui oblige le compilateur à avoir une certaine intelligence pour analyser si on a traitement local ou pas.

[e-ric]

Salut

Est-ce que le code suivante ne suffirait pas ?

Code :

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

1
2
3
4
5
6
7
 
function DoAllTasks: boolean;
begin
  result:= DoTask1;
  result:= DoTask2 and result;
  ...
end;

cdlt

e-ric

[e-ric]

Re-salut

Tu peux désactiver localement les évaluations booléennes :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
{$B+} 
function DoAllTasks: boolean;
begin
  result:= true;
  result:= result and DoTask1;
  result:= result and DoTask2;
  ...
end;
{$B-}

Ce qui suppose que le reste de ton application optimise les évaluations booléennes.

cdlt

e-ric

[Linkin]

Il me semble (à vérifier) qu'en faisant:

Code :

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

1
2
 
Result := DoTaskn and Result;

Delphi n'utilise pas l'optimisation

[Stef_D]

Salut

Est-ce que le code suivante ne suffirait pas ?

Code :

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

1
2
3
4
5
6
7
 
function DoAllTasks: boolean;
begin
  result:= DoTask1;
  result:= DoTask2 and result;
  ...
end;

cdlt

e-ric

Malheureusement non ça revient exactement à la première portion de code de mon précédent message. Delphi va optimiser...
J'ai fais exprès de mettre "result:= true" en première ligne pour appuyer le parallèlle entre les 2 codes qui semblent quasi identiques mais qui ne produisent pas le même effet.

Tu peux désactiver localement les évaluations booléennes

Effectivement mais je trouve cette solution pas très "élégante".
Ca fait un peu bricolage pis faut y penser à chaque fois.
En fait surtout j'aimerai savoir pourquoi Delphi agit ainsi ? ça me semble pas logique.

Il me semble (à vérifier) qu'en faisant:

Code :

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

1
2
 
Result := DoTaskn and Result;

Delphi n'utilise pas l'optimisation

Je t'assure que si, et c'est bien ça que je trouve absurde :-/

Edit : ouppss, non tu as raison, pas dans ce cas justement.
Comme l'a dit e-ric juste avant =)

[anapurna]

salut

les dotask ramene un boolean de quel type ?
je m'explique il peut arriver des probleme sur la recuperation de valeur boolean recupere d'une dll ecrite en c

car en delphi true et false sont equivalent a 0 ou 1 alors qu'en c c'est 1 ou different de 1 ce qui n'est pas la meme chose lorsque tu applique les operateur boolean


@+ Phil

[Stef_D]

salut

les dotask ramene un boolean de quel type ?
je m'explique il peut arriver des probleme sur la recuperation de valeur boolean recupere d'une dll ecrite en c

car en delphi true et false sont equivalent a 0 ou 1 alors qu'en c c'est 1 ou different de 1 ce qui n'est pas la meme chose lorsque tu applique les operateur boolean


@+ Phil

Ce sont des booleans, le type interne à Delphi. Je parle de Delphi uniquement ^^

[Philippe Gormand]

Vérifis l'option de compilation "Evaluation booléene complete".

[Stef_D]

Vérifis l'option de compilation "Evaluation booléene complete".

Oui je connais cette option, mais je ne veux pas l'activer car une expression du type :
if ((obj <> nil) and (obj.isReady)) va provoquer des erreurs.

quand je parlais de mots clés ou autre, je pensais plutot à un mot clé qui permettrait de spécifier à Delphi que telle ou telle fonction ne doit pas être optimisée sur l'évaluation booléenne. Mais en fait je ne pense pas que ce genre de mot clé existe... en fait c'est plutot que j'aimerai comprendre pourquoi Delphi se comporte de manière différente dans les 2 cas. Ca fait pas très... rigoureux pour un langage de programmation ? rigoureux n'est pas le mot qui convient le mieux mais je ne le retrouve plus.

[e-ric]

C'est très curieux, je pensais que l'optimisation suivait l'ordre des opérandes, à savoir que la valeur de la première opérande (cellle de gauche) décidait de l'évaluation de la seconde (celle de droite), d'où ma proposition d'inverser l'ordre des opérandes.

Dans ce cas, tu n'a pas le choix, utilise la directive conditionnelle {B+} (ou {$BOOLEVAL ON} plus explicite). C'est la solution la plus simple et la plus concise.

Plein de bonnes raisons
- Ce n'est pas moins esthétique, c'est concis et suffisant.
- Cela permet de conserver les optimisations pour le reste du code.
- Cela avertit le développeur de maintenance (ou peut-être toi dans quelques mois) du comportement particulier de cette fonction.
- Enfin cela te permet d'écrire un code relativement simple auto-documenté.

L'élégance est une notion relative, l'efficacité est franchement nécessaire.

En tant que développeur Delphi, je travaille toujours avec l'hypothèse de l'évaluation booléenne paresseuse. Le fait de voir une telle directive m'incite à approfondir l'analyse (à l'aide de F1).

cdlt

e-ric

[Stef_D]

C'est très curieux, je pensais que l'optimisation suivait l'ordre des opérandes, à savoir que la valeur de la première opérande (cellle de gauche) décidait de l'évaluation de la seconde (celle de droite), d'où ma proposition d'inverser l'ordre des opérandes.

Dans ce cas, tu n'a pas le choix, utilise la directive conditionnelle {B+} (ou {$BOOLEVAL ON} plus explicite). C'est la solution la plus simple et la plus concise.

Plein de bonnes raisons
- Ce n'est pas moins esthétique, c'est concis et suffisant.
- Cela permet de conserver les optimisations pour le reste du code.
- Cela avertit le développeur de maintenance (ou peut-être toi dans quelques mois) du comportement particulier de cette fonction.
- Enfin cela te permet d'écrire un code relativement simple auto-documenté.

L'élégance est une notion relative, l'efficacité est franchement nécessaire.

En tant que développeur Delphi, je travaille toujours avec l'hypothèse de l'évaluation booléenne paresseuse. Le fait de voir une telle directive m'incite à approfondir l'analyse (à l'aide de F1).

cdlt

e-ric

Merci pour toutes ces réponses

Edit : me revoilà...

D'après toi, si on change le code en :

Code :

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

1
2
 
result:= DoTask1 and result;

Ca fonctionnerait ? A voir
Sinon ça serait assez marrant puisqu'on aurait :

Code :

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

1
2
 
result:= result and DoTask1;

et

Code :

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

1
2
 
result:= DoTask1 and result;

qui produirait un résultat différent "d'éxécution"...

Sinon effectivement on peut choisir de toujours désactiver les optimisations d'évaluations des expressions booléennes, malheureusement on a pas commencé notre logiciel avec cette logique et l'activation de cette option entrainerait un sacré paquet de nouveaux bugs ^^ Mais encore, ce n'est pas réellement une solution que je cherche puisque ma bidouille de passer par une variable temporaire fonctionne. Ce que je cherche à comprendre, c'est pourquoi déjà cette bidouille fonctionne (elle ne devrait pas puisque si Delphi optimiserait jusqu'au bout, ça ne changerait rien) et surtout pourquoi l'expression booléenne global n'est pas évaluée lorsqu'on a un appel de fonction dedans.
En lisant l'aide de Delphi, j'ai vu qu'un variant provoque l'évaluation totale de l'expression, mais pourquoi en-t-il pas de même pour les fonctions ?

2ème Edit :
après essai l'utilisation de

Code :

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

1
2
 
result:= DoTask1 and result;

à la place de

Code :

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

1
2
 
result:= result and DoTask1;

Suffit à contourner le problème, tout simplement à cause du sens de l'évaluation qui se fait de gauche à droite.
Tu avais raison e-ric sur ta première réponse, je viens seulement de m'en rendre compte (j'avais pas vu que tu avais inversé les 2 opérandes) ^^
Mais bon quelque part, ça me choque :-/

[slimjoe]

Merci pour toutes ces réponses

Ca fonctionnerait ? A voir
Sinon ça serait assez marrant puisqu'on aurait :

Code :

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

1
2
 
result:= result and DoTask1;

et

Code :

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

1
2
 
result:= DoTask1 and result;

qui produirait un résultat différent "d'éxécution"...

Je dois n'avoir rien compris à la problématique parce que je trouve absolument logique que ça puisse provoquer des résultats différents.

Code :

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

1
2
 
result:= result and DoTask1;

Si result est faux, du point de vue de la logique de Bool, le résultat de DoTask1 ne sert plus à rien, le résultat total va donner faux quel que soit celui de DoTask1. Delphi, en RAD performant, décide de ne pas exécuter DoTask1.

Code :

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

1
2
 
result:= DoTask1 and result;

Delphi lit de gauche à droite. Si c'est inversé, Delphi va tester (donc exécuter) DoTask1 et décider par la suite s'il teste result ou non.

Du point de vue booléen, c'est parfaitement logique.

[edam]

Code :

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

1
2
3
4
5
6
7
function DoAllTasks: boolean;
begin
  result:= true;
  result:= result and DoTask1;
  result:= result and DoTask2;
  ...
end;

a prut prés :

Code :

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

1
2
3
4
5
6
7
 
result:=false;
if not Dotask1 then exit;
if not Dotask2 then exit;
...
if not Dotaskn then exit;
result:=true;

en plus la réponse tu la dis toi meme

Le but de ma fonction est donc de faire tout les traitements (qui influent de manière "globale" sur l'application), elle retourne vrai si tout s'est déroulé correctement, faux sinon.

alors si une et une seul est faux pas la pein d'executé le réste est sa c'est une point fort en delphi (bravo à borland pour son travail d'optimisation en delphi) ,,,
si tu veux que tous tes fonction s'excute , tu peut par example incémenté un variable et tu le compare a la fin avec une valeur (nbr de fonction):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
function DoAllTasks: boolean;
var  i:integer;
begin
  i:=0;
  if DoTask1 then inc(i);
  if DoTask2 then inc(i);
....
  if DoTaskn then inc(i);
   result:=(i=n);
end;

si tu as besoin simplement de savoir si au moins de tes fonction retourne vrait utlise plutot (OR)

Code :

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

1
2
3
4
5
6
7
function DoAllTasks: boolean;
begin
  result:= false;
  result:= result or DoTask1;
  result:= result or DoTask2;
  ...
end;

[e-ric]

Les choix d'optimisation ne sont pas criticables en soi, on est bien contents de les trouver. Un langage de programmation n'est pas un discours mathématiques, il y a des considérations d'efficacité et de faisabilité. Le concepteur du langage fait des choix. Il faut s'en tenir à cela.

C'est au développeur de connaître ces particularités. C'est son boulot. Je ne suis pas sûr que les compilateurs C ou C++ fassent tant de miracles que cela. Personnellement, je préfère Delphi car la sémantique est plus simple et le contrôle des types plus musclé, en outre, il compile très vite (on peut accroître la fréquence des tests)

Enfin, il est envisable de ne pas exécuter la suite d'un traitement si l'une des parties du traitement a échoué (c'est même le plus courant). En ce qui concerne ta fonction, si elle retourne False, on sait qu'une partie a échoué mais on ne sait pas déterminer laquelle (sauf si des indications sont fournies par les DoTaskN). Si les traitements sont dépendants, l'erreur d'une tâche peut avoir des conséquences sur les suivantes.

Cdlt

e-ric

[Stef_D]

Les choix d'optimisation ne sont pas criticables en soi, on est bien contents de les trouver. Un langage de programmation n'est pas un discours mathématiques, il y a des considérations d'efficacité et de faisabilité. Le concepteur du langage fait des choix. Il faut s'en tenir à cela.

C'est au développeur de connaître ces particularités. C'est son boulot. Je ne suis pas sûr que les compilateurs C ou C++ fassent tant de miracles que cela. Personnellement, je préfère Delphi car la sémantique est plus simple et le contrôle des types plus musclé, en outre, il compile très vite (on peut accroître la fréquence des tests)

Enfin, il est envisable de ne pas exécuter la suite d'un traitement si l'une des parties du traitement a échoué (c'est même le plus courant). En ce qui concerne ta fonction, si elle retourne False, on sait qu'une partie a échoué mais on ne sait pas déterminer laquelle (sauf si des indications sont fournies par les DoTaskN). Si les traitements sont dépendants, l'erreur d'une tâche peut avoir des conséquences sur les suivantes.

Cdlt

e-ric

Personnellement je trouve que si justement, les choix d'optimisation sont criticables, justement dans ce cas précis. Je demande pas de supprimer les optimisations, mais juste de les faire intelligement.
C'est une question de choix... Pour moi le compilateur doit faire ce que tu lui demandes en gardant une cohérence sur le traitement de l'information.
J'aime le Delphi pour sa simplicité et son efficacité mais je préfère le C++ qui offre plus de liberté et me semble plus rigoureux quand aux optimisations...

Après tu dis c'est au développeur de connaitre les particularités du langage. Certes, mais il est impossible de tout connaitre le fonctionnement interne du compilo, là c'est un cas simple, mais y'a des cas très complexes qui te prendrait un temps dingue à analyser, surtout que l'aide du delphi est assez radin sur ce genre d'info. Par exemple j'ai pas mal galéré pour comprendre ce que faisait Delphi quand tu lui passais un 'record' en paramètre, ou pire, lorsqu'une fonction retourne un record (Garbage Collector pour le libérer ?) !

Sinon concernant le traitement qui doit s'interrompre si une erreur intervient, oui c'est souvent le cas, mais le compilateur doit le faire uniquement si tu lui demandes :
if (DoTask1) then
if (DoTask2) then...

[slimjoe]

Je trouve que si justement, les choix d'optimisation sont criticables

En fait, tout dans la vie peut être sujet à la critique .

Mais personellement, je pense que dans le cas présent c'est un peu futile. Je suis d'accord avec Stef_D, y'a des choses décevantes qui se passent dans l'environnement Delphi mais je rejoins également e-ric sur ce point : le travail du programmeur est de connaître à fond les outils (les forces autant que les faiblesses) de façon à être en mesure de choisir le bon dépendemment de la situation.

À moins qu'on se porte acquéreurs de l'EDI.
Intéressé ?

[edam]

[e-ric]

C'est une question de sensibilité !

En ce qui concerne la règle d'optimisation sur les évaluations booléennes, elle est claire (je l'ai mentionnée plus haut) et invariable, le développeur Delphi doit l'avoir à l'esprit et faire son code en conséquence. De même, l'analyse du comportement d'un programme se fait à l'aune de cette connaisance. Pas d'expertise sinon. Tous les langages ont leur propres règles, c'est comme çà.

Tout cela me rappelle un collègue et très bon copain par ailleurs qui n'arrêtait pas de critiquer Delphi par dépit de ne pouvoir programmer en langage C/C++ (ses petits favoris).

Delphi n'est certes pas parfait (quel langage l'est ??), je lui reproche bien des choses comme :
- les faiblesses du modèle objet (pas de type générique, pas d'héritage multiple, uniquement une sémantique de référence et j'en oublie)
- l'impossibilité de déboguer sereinement si l'optimisation est activée.
- ...
Mais bon cela ne m'empêche pas d'apprécier ce compilo rapide et robuste.

e-ric

[Stef_D]

a prut prés :
alors si une et une seul est faux pas la pein d'executé le réste est sa c'est une point fort en delphi (bravo à borland pour son travail d'optimisation en delphi) ,,,

Justement non, ça me pose problème ça.
Si la fonction fait un traitement local qui n'influe pas sur le reste ok, mais si ce n'est pas le cas, le compilateur n'a pas à ignorer ta fonction...
Au contraire, je trouve que Borland a fait preuve de légèreté en choisissant un tel comportement...

si tu as besoin simplement de savoir si au moins de tes fonction retourne vrait utlise plutot (OR)

Code :

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

1
2
3
4
5
6
7
function DoAllTasks: boolean;
begin
  result:= false;
  result:= result or DoTask1;
  result:= result or DoTask2;
  ...
end;

Oui mais là pareil, si la première fonction renvoie vrai alors les autres ne sont plus exécutées !

[edam]

Oui mais là pareil, la première fonction renvoie vrai, les autres ne sont plus exécutées !

oui c'est vrait
alors pourqoi pas :

Code :

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

1
2
3
4
5
6
7
8
9
10
function DoAllTasks: boolean;
var  i:integer;
begin
  i:=0;
  if DoTask1 then inc(i);
  if DoTask2 then inc(i);
....
  if DoTaskn then inc(i);
   result:=(i=n);
end;