Discussion :

[alainvh]

Bonjour,

Au terme de sa discussion d'avril 2007, Dereck07 fournit le code permettant de récupérer un résultat array of string d'une fonction en déclarant un type. Voici son code (qui fonctionne ).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
type TIntArray = array[-1..1] of integer;
 
function giveT(v:integer):TIntArray ;
var
 t:TIntArray;
begin
 t[-1]:=v;
 t[0]:=v+1;
 t[1]:=v+2;
 result:=t;
end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  t1:TIntArray;
begin
  t1:=giveT(2);
  memo1.Lines.Add(inttostr(t1[-1])+' - '+inttostr(t1[0])+' - '+inttostr(t1[1]));
end;

Je m'en suis inspiré largement. Mon projet : une fonction partagée installée dans une unité (UnitTool) doit retourner à une fiche (Form1/Unit1) un résultat array of string. Voici mon code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
unit UnitTool;

interface

uses
  SysUtils, Dialogs;

type
  TTableauChaines = array of string;

function ChargeTableau:TTableauChaines;

implementation

function ChargeTableau:TTableauChaines;
var Tableau:TTableauChaines;
    i:integer;
begin
  for i:=0 to 4 do
    begin
      SetLength(Tableau,i+1);
      Tableau[i]:=IntToStr(i);
      ShowMessage(Tableau[i]);  // <--- pour vérifier le fonctionnement
    end;
  result:=Tableau;
end;

end.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TTableauChaines = array of string;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;

var
  Form1: TForm1;

implementation

uses UnitTool;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var MonTableau:TTableauChaines;
begin
  MonTableau:=ChargeTableau; // <--- ici, plantage
  //ChargeTableau;  // <---- ici, ça marche, mais aucun intérêt !!!
end;

end.

A la construction, plantage avec message Types incompatibles ! Pourtant, la variable MonTableau et le résultat de la fonction sont de type TTableauChaines !!!

Cordialement,
Alain

[Rayek]

Normal tu as deux types TTableauChaines différents, Celui dans UnitTool et celui dans Unit1. Ce n'est pas parce qu'ils ont le même nom que c'est les mêmes.

Pour régler le problème il te faut seulement virer le TTableauChaines dans Unit1 et mettre le UnitTool dans les uses de la partie interface (et pas dans celle de l'implémentation)

[alainvh]

Merci, Rayek.

Ta solution fonctionne . C'est "Normal" pour toi, est-ce que cela le deviendra un jour pour moi ?
En fait, entre plein d'autres lacunes, je ne capte pas bien la différence entre la déclaration Uses en Interface et la déclaration Uses en Implementation : peut-être même n'ai-je pas une idée très claire de la différence entre Interface et Implementation ? A potasser...

Cordialement,
Alain

[ShaiLeTroll]

Je dirais même qu'il existe TStringDynArray déclaré en standard dans l'unité Types.pas

Tu peux résumer interface comme étant la partie publique de l'unité lorsque l'inclut à une autre unité, la partie implémentation étant privée !

L'Analyse du Compilateur est en deux passes, il va lire toutes les sections interface puis va compiler toutes les sections implementation (bon c'est plus compliqué, mais je n'en sais pas plus)

Les Uses dans la partie implémentation ne sont ajoutées qu'au moment de compiler le code de cette partie, cela évite des éventuelles référence circulaire quand deux unités s'utilise l'une et l'autre dans leur partie interface (le compilateur ne peut pas gérer une récursivité !)

[alainvh]

Merci ShaiLeTroll.
Si j'ai bien compris ton explication Interface-Implementation, toutes les Interfaces de n. unités d'un même projet sont regroupées ensemble à la compilation, et cet ensemble est accessible à toutes les unités.
Quant à TStringDynArray, je ne savais pas que cela existait : à essayer.

Cordialement,
Alain

[Paul TOTH]

Merci ShaiLeTroll.
Si j'ai bien compris ton explication Interface-Implementation, toutes les Interfaces de n. unités d'un même projet sont regroupées ensemble à la compilation, et cet ensemble est accessible à toutes les unités.
Quant à TStringDynArray, je ne savais pas que cela existait : à essayer.

Cordialement,
Alain

Non, les dépendances entre unités sont toujours explicites.

en fait pour comprendre le langage Pascal il faut savoir que le compilateur part du .DPR et lit les lignes dans l'ordre.
Quand il rencontre une clause USES il ouvre les unités dans leur ordre d'apparition
Pour chaque unité il compile la partie Interface (ce qui implique la compilation des interfaces des unités de la clause USES de ces unités)
Une fois la partie interface d'une unité compilée, il s'assure que la partie implémentation de toutes les unités de sa clause USES sont également compilées.
finalement il vérifie que la partie implémentation des unités de la clause USES du programme sont compilées et termine la compilation du DPR.

ça c'est pour l'ordre de lecture du projet, il en résulte que pour retrouver un symbole, le compilateur recherche en remontant le code (tout déclaration doit précéder son usage), s'il tombe sur un USES il parcours l'interface des unités de la dernière à la premier mais sans récursivité (pas dans les unités de l'unité), puis remonte encore le code jusqu'à trouver le symbole (ou pas).

Du coup si ton projet déclare deux unités qui déclarent deux types ayant le même nom, c'est celle qui apparaît en second dans le USES qui sera choisie...sauf à préfixer le nom du nom de l'unité (unit1.Type1)

[alainvh]

Merci, Paul TOTH.
Ça m'éclaire... un peu . Alors, je propose un exemple.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
program Project1;
 
uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas',
  Unit3 in 'Unit3.pas';
 
{$R *.res}
 
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.
 
******************************************************
unit Unit1;
 
interface
 
uses  Windows,SysUtils;
 
type
  TForm1 = class(TForm) 
  end;
 
var
  Form1: TForm1;
 
implementation
 
use Unit3;
 
******************************************************
uses Unit2;
 
interface
 
uses Unit3;
 
implementation
 
end.
 
******************************************************
unit Unit3;
 
interface
 
implementation
 
uses Unit1;
 
end.

Pour moi, la compilation se ferait ainsi (dans l'ordre du DPR).
-Compilation de Unit1 :
Interface de Unit1, Interface et Implementation de Windows, Interface et Implementation de SysUtils, Implementation de Unit1 : là se trouve Uses Unit3, donc compilation de l'Interface et de l'Implementation de Unit3 : à se trouve Uses Unit1, mais déjà compilé.
-Compilation de Unit2 :
Interface de Unit2, Implementation de Unit2 : là se trouve Uses Unit1, mais déjà compilé.
-Compilation de Unit3 :
Déjà compilé.
Fin...

Si je suis vraiment à côté de la plaque, laisse tomber, mon cas est désespéré , sinon, quelle est en fait la différence entre une déclaration Uses en Interface et en Implementation ?

En tout cas, merci de me donner un peu de ton temps !

Cordialement,
Alain

[Paul TOTH]

tu peux mettre toutes les unités dans le uses de l'interface...tant que tu n'as pas de pb de référence circulaire

[alainvh]

Merci beaucoup, Paul TOTH.
Tes deux réponses viennent de me faire comprendre -du moins je l'espère- le concept de 'référence circulaire' (grâce à ton lien). Constat : on doit se plier à la logique du compilateur de Delphi, d'où l'importance de la connaître à peu près.

Bonne soirée,
Alain

[Paul TOTH]

Merci beaucoup, Paul TOTH.
Tes deux réponses viennent de me faire comprendre -du moins je l'espère- le concept de 'référence circulaire' (grâce à ton lien). Constat : on doit se plier à la logique du compilateur de Delphi, d'où l'importance de la connaître à peu près.

Bonne soirée,
Alain

exactement, ça agace un certain nombre de développeurs qui préfèrent que le compilateur se plie à leur logique de programmation, mais dans les faits j'ai très rarement rencontré le pb de référence circulaire dans mes projets

[alainvh]

exactement, ....

Merci ! Ça, c'est une belle réponse : psychologiquement, ça réconforte, j'ai compris un peu quelque chose .
J'ai encore une difficulté pour terminer mon application, je vais donc proposer une nouvelle discussion...

Cordialement,
Alain