Discussion :

[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 !

[Stef_D]

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 :

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

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 :

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

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

[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;

[slimjoe]

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.

[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é ?

[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

[edam]

[e-ric]

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

Code :

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

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

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

[Stef_D]

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 :

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

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 :

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

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 :

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

[e-ric]

je reconnais c'est curieux.

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

[Stef_D]

je reconnais c'est curieux.

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

En effet... bon WE