function boolean --> logique delphi douteuse ?

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:

---

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:

---

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.

Salut

Est-ce que le code suivante ne suffirait pas ?

Code:

---

1 2 3 4 5 6 7

function DoAllTasks: boolean; begin result:= DoTask1; result:= DoTask2 and result; ... end;

---

cdlt

e-ric

Re-salut

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

Code:

---

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

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

Code:

---

1 2	Result := DoTaskn and Result;

---

Delphi n'utilise pas l'optimisation

Citation:

---

Envoyé par e-ric

Salut

Est-ce que le code suivante ne suffirait pas ?

Code:

---

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.

Citation:

---

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.

Citation:

---

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

Code:

---

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 =)

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

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

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

Citation:

---

Envoyé par 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

---

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

Citation:

---

Envoyé par Philippe Gormand

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

---

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.

Citation:

---

Envoyé par 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

---

Merci pour toutes ces réponses :)

Edit : me revoilà...

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

Code:

---

1 2	result:= DoTask1 and result;

---

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

Code:

---

1 2	result:= result and DoTask1;

---

et

Code:

---

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:

---

1 2	result:= DoTask1 and result;

---

à la place de

Code:

---

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 :-/

Citation:

---

Envoyé par Stef_D

Merci pour toutes ces réponses :)

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

Code:

---

1 2	result:= result and DoTask1;

---

et

Code:

---

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:

---

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:

---

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.

Citation:

---

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.

---

Je ne comprends pas... Est-ce que tu veux que Delphi devine quand l'optimisation booléenne fait ton affaire ?

Encore une fois, je n'ai probablement pas compris le problème...

Désolé pour les post multiples, je suis en feu :)

Citation:

---

en fait c'est plutot que j'aimerai comprendre pourquoi Delphi se comporte de manière différente dans les 2 cas.

---

Delphi ne se comporte pas de manière différente. Il exécute le code de haut vers le bas et de la gauche vers la droite. Donne lui 2 instructions différentes et c'est normal que les résultats soient différents mais le comportement est le même.

Mais bon.... Comme je l'ai dit souvent, laissez moi m'auto-citer :

Citation:

---

Envoyé par slimjoe

je n'ai probablement pas compris le problème...

---

;)

Je comprend tes préoccupations mais je pense que tu n'as pas compris ce que je t'ai proposé.

Le fait qu'il y ait une évaluation booléenne paresseuse implique que le compilateur choisisse selon une règle précise et connue quelle opérande (droite ou gauche) il va évaluer en premier. en respectant l'associativité de l'opérateur AND, c'est évidemment l'opérande de gauche. Fais le test.

Contrairement aux mathématique pures, l'évaluation du résultat d'un expression suit par un ordre séquentiel. D'où la nécessité de connaître l'odre d'évaluation de opérandes pour un opérateur donné.

En ce qui concerne la directive B+ elle est valide jusqu'au prochain B- donc pas de problème en ce qui concerne le reste de ton code.

C'est clair ???

cdlt

e-ric

Citation:

---

Envoyé par slimjoe

Je ne comprends pas... Est-ce que tu veux que Delphi devine quand l'optimisation booléenne fait ton affaire ?

Encore une fois, je n'ai probablement pas compris le problème...

---

En gros oui, d'autres langages comme le C/C++ le font très bien.
Et surtout le Delphi le fait bien pour les expressions incluant des variants (surement une contrainte interne), pourquoi ne pas avoir forcé cette contrainte lorsque des fonctions sont utilisées dans l'expression ?
Si la fonction a une ouverture globale et non locale dans le programme, il est absurde de penser que le compilateur va ignorer son éxécution dans un soucis d'optimisation. Enfin moi ça me semble absurde...

Citation:

---

Envoyé par e-ric

Je comprend tes préoccupations mais je pense que tu n'as pas compris ce que je t'ai proposé.

Le fait qu'il y ait une évaluation booléenne paresseuse implique que le compilateur choisisse selon une règle précise et connue quelle opérande (droite ou gauche) il va évaluer en premier. en respectant l'associativité de l'opérateur AND, c'est évidemment l'opérande de gauche. Fais le test.

Contrairement aux mathématique pures, l'évaluation du résultat d'un expression suit par un ordre séquentiel. D'où la nécessité de connaître l'odre d'évaluation de opérandes pour un opérateur donné.

En ce qui concerne la directive B+ elle est valide jusqu'au prochain B- donc pas de problème en ce qui concerne le reste de ton code.

C'est clair ???

cdlt

e-ric

---

Oui oui j'ai bien compris ce que tu voulais me dire, merci.
En fait j'ai mal lu ton premier post mais qui répondait exactement au problème. Cependant (après c'est plutot de l'ordre du débat) je ne trouve pas forcément cette approche logique d'un point de vue algorithmique...
Comme je disais, si task1 modifie "globalement" (désolé de répéter ce terme mais il me semble approprié) le programme, le compilateur ne devrait pas optimiser le code ainsi, du coup c'est à "l'utilisateur" (le développeur reste un utilisateur ici) de prendre garde à ça.

De même on revient sur le tout premier cas que j'ai cité :

Code:

---

1 2 3 4 5 6 7

function DoAllTasks: boolean; begin result:= DoTask1; result:= result and DoTask2; ... end;

---

qui produit un résultat différent de :

Code:

---

1 2 3 4 5 6 7 8 9 10

function DoAllTasks: boolean; var b: boolean; begin result:= DoTask1; b:= DoTask2; result:= result and b; ... end;

---

bizarre nan ?

Citation:

---

Envoyé par Stef_D

Code:

---

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:

---

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

Citation:

---

Envoyé par Stef_D

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:

---

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:

---

1 2 3 4 5 6 7

function DoAllTasks: boolean; begin result:= false; result:= result or DoTask1; result:= result or DoTask2; ... end;

---

Citation:

---

Envoyé par Stef_D

Code:

---

1 2 3 4 5 6 7

function DoAllTasks: boolean; begin result:= DoTask1; result:= result and DoTask2; ... end;

---

qui produit un résultat différent de :

Code:

---

1 2 3 4 5 6 7 8 9 10

function DoAllTasks: boolean; var b: boolean; begin result:= DoTask1; b:= DoTask2; result:= result and b; ... end;

---

bizarre nan ?

---

Bizarre ? Non. Un peu dommage ? Probablement.

Le problème vient du fait que Delphi n'optimise sur une aussi longue portée qu'on le voudrait parfois.

Dans le code suivant :

Code:

---

1 2 3 4 5 6

var s: string; begin s := 'Test'; end;

---

La ligne s := 'Test'; n'est pas compilée par Delphi. Toutefois, si tu fais :

Code:

---

1 2 3 4 5 6 7

var s1, s2: string; begin s1 := 'Test'; s2 := s1; end;

---

La ligne s := 'Test'; va être compilée. Delphi ne va pas plus loin que la première ligne quand vient le temps d'optimiser.

C'est probablement ce qu'il se passe avec ton cas #2 de tests booléens.


[EDIT] Bon... Quand ça va bien.... Je viens de tester mon code et ça compile tout partout... Pourtant j'aurais juré.... Veuillez ignorer ce post alors....

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

Citation:

---

Envoyé par edam

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...

Citation:

---

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

Code:

---

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 !

Citation:

---

Envoyé par slimjoe

Bizarre ? Non. Un peu dommage ? Probablement.

Le problème vient du fait que Delphi n'optimise sur une aussi longue portée qu'on le voudrait parfois.

Dans le code suivant :

Code:

---

1 2 3 4 5 6

var s: string; begin s := 'Test'; end;

---

La ligne s := 'Test'; n'est pas compilée par Delphi. Toutefois, si tu fais :

Code:

---

1 2 3 4 5 6 7

var s1, s2: string; begin s1 := 'Test'; s2 := s1; end;

---

La ligne s := 'Test'; va être compilée. Delphi ne va pas plus loin que la première ligne quand vient le temps d'optimiser.

C'est probablement ce qu'il se passe avec ton cas #2 de tests booléens.


[EDIT] Bon... Quand ça va bien.... Je viens de tester mon code et ça compile tout partout... Pourtant j'aurais juré.... Veuillez ignorer ce post alors....

---

Ca m'étonne vraiment que le niveau d'optimisation de delphi se cantonne 1 ligne pour ce genre de dépendance, c'est vraiment faible. J'entend souvent que Delphi optimise bien le code, ça serait étonnant en partant ainsi...

Edit: t'as activé les optimisations ? ^^
Bizarre quand même...

Citation:

---

Envoyé par Stef_D

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

---

oui c'est vrait :oops: :oops:
alors pourqoi pas :

Code:

---

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;

---

Citation:

---

Envoyé par Stef_D

Edit: t'as activé les optimisations ? ^^
Bizarre quand même...

---

Je dois avoir un problème avec les optimisations sur mon poste effectivement. J'ai déjà donné cet exemple (et je l'avais testé à l'époque) et ça fonctionnait. Je compte retester une fois à la maison.

Citation:

---

Envoyé par 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

---

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...

Citation:

---

Envoyé par Stef_D

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é ? ;)

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

:oops:

Citation:

---

Envoyé par edam

avec {$B}. active tuas pas essayé:

Code:

---

1 2	result:=DoTask1 and DoTask2 and ...and DoTaskn;

---

---

J'ai déjà proposé la solution !!!

Il est vrai que le débat est un peu futile...
Parfois en regardant mes lignes de code je me dis "bon après tout..." et d'autres fois où vraiment j'arrive pas à me mettre dans cette logique...

Le plus choquant restant cet exemple :

Code:

---

1 2 3 4 5 6 7

function DoAllTasks: boolean; begin result:= DoTask1; result:= result and DoTask2; ... end;

---

qui produit un résultat différent de :

Code:

---

1 2 3 4 5 6 7 8 9 10

function DoAllTasks: boolean; var b: boolean; begin result:= DoTask1; b:= DoTask2; result:= result and b; ... end;

---

... enfin :)

Edit :

Concernant ça :

Citation:

---

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

---

Si ton expression booléenne contient un variant (même s'il est de type varBool), alors l'expression sera évaluée en entière quoiqu'il arrive... c'est un détail mais qu'il doit être source de belles erreurs parfois ;)

je reconnais c'est curieux.

Bon WE, nous nous sommes bien amusés quand même...

Citation:

---

Envoyé par e-ric

je reconnais c'est curieux.

Bon WE, nous nous sommes bien amusés quand même...

---

En effet... bon WE :)