Discussion :

[looping]

bonjour,

Comme je suis autodidacte, j'ai parfois des lacunes sur des fondamentaux.

Sur les 3 bases de code suivantes, j'ai placé une variable à différents endroits

Voici ma question: quelle est la différence entre les 3 versions

Cas N°1

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
unit Unit1;

interface

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

type
  TForm1 = class(TForm)
  private
  mavariable:integer;
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

end.

cas N°2

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
unit Unit1;

interface

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

type
  TForm1 = class(TForm)
  private
     { Déclarations privées }
  public
  mavariable:integer;
    { Déclarations publiques }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

end.

cas N°3

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
unit Unit1;

interface

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

type
  TForm1 = class(TForm)
  private
     { Déclarations privées }
  public
     { Déclarations publiques }
  end;

var
  Form1: TForm1;
 mavariable:integer;


implementation

{$R *.dfm}

end.

Le font de ma question c'est comment déclarer des variables globales.
Je sais , il faut éviter, mais j'en ai que 3 sur tout mon projet.
Jusqu'a présent j'utilisais le cas N°3, mais est ce que le cas N°1 fonctionne aussi.
Le problème est qu'il faut declarer uses unit1 dans la form où est utilisée la variable, et je crains les références circulaires.

Est ce qu'il y a d'autres possiblité de déclarer des variables globale ?


cordialement

[Okaryn]

Dans le 1er cas, ta variable n'est accessible que dans TForm1, elle est masquée au reste de ton programme (partie private).

Dans le 2ème cas, elle est publique et affectée à TForm1. N'importe qui ayant accès à Tform1 peut l'utiliser via TForm1.mavariable

Dans le 3ème, on y accède directement en référençant uniquement Unit1.

La 1) n'est donc pas du tout appropriée pour une variable globale. La 2 et 3 "peuvent" l'être, mais il y a, comme tu l'indiques, de gros risques de références circulaires dès l'instant que tu as besoin d'accéder aux composants entre unités.

Les quelques fois où j'ai eu besoin de variables globales, j'ai utilisé une de ces 2 méthodes :

1/ Déclarer la variable dans le projet (fichier DPR), tout le monde y a donc accès implicitement

2/ Créer une unité contenant toutes mes variables et en référençant cette unité partout. Elle ne contenait aucun composant, juste variables et fonctions globales.

[Andnotor]

Dans le 1er cas, ta variable n'est accessible que dans TForm1, elle est masquée au reste de ton programme (partie private).

Pas tout à fait. Elle est accessible depuis partout dans l'unité courante. Pour qu'elle ne le soit vraiment que par TForm1, il faut que la section soit strict private.

1/ Déclarer la variable dans le projet (fichier DPR), tout le monde y a donc accès implicitement

Une application console éventuellement, sinon pas

Dans les cas généraux et si la variable n'est pas dépendante de TForm1, mieux vaut ne pas l'y inclure comme membre. Une unité ne contenant que les variables et constantes est préférable et plus lisible.

[Okaryn]

Une application console éventuellement, sinon pas

C'est pas beau de vieillir, on s'invente des trucs qui n'existent pas

[Paul TOTH]

une variable globale (qui n'a rien de "pas bien") est forcément la solution 3.

les solutions 1 et 2 créent autant de variables "mavariable" qu'il y a d'instance de TForm1. Et si la variable globale Form1 pointe sur une instance de TForm1, alors, avec la solution 2, Form1.mavariable permet d'accéder à cette instance de mavariable.

comme indiqué plus haut, la solution 1 ne rend "mavariable" accessible que depuis une méthode de TForm1 ou d'un code à l'intérieur de l'unité.

[Nono40]

une variable globale (qui n'a rien de "pas bien") est forcément la solution 3.

+1

Si les variables globales que tu ajoutes ne sont pas directement liées à TForm1 il est préfarable de les grouper dans une unité commune sans fiche.
Quand le projet a beaucoup de fiches on sais ou les chercher.

J'utilise 3 si la variables est très fortement liée à la fiche de l'unité ou l'unité elle-même.

Si la variable dépend de l'instance de TForm1 et que TForm1 est créée plus d'une fois, alors c'est la solution 2 qui devient obligatoire.

[ShaiLeTroll]

il manque une solution (pour Delphi 2005+) : Champs de classe

Code :

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

1
2
3
4
5
6
7
8
type
  TForm1 = class(TForm)
  private
     { Déclarations privées }
  public
    { Déclarations publiques }
    class var mavariable: integer;
  end;

un équivalent pour D3 à D7 en utilisant une variable globale "masquée" dans la section implementation

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
type
  TForm1 = class(TForm)
  private
     { Déclarations privées }
  public
    { Déclarations publiques }
    class function Getmavariable: Integer;
    class function Setmavariable(Value: Integer);
  end;
 
implementation
 
// Après implementation donc masquée accessible uniquement via Accesseur
var
  _mavariable: Integer = 0;
 
class function TForm1.Getmavariable: Integer;
begin
  Result := _mavariable;
end;
 
class function TForm1.Setmavariable(Value: Integer);
begin
  _mavariable := Value;
end;

Chaque emplacement a une raison d'être !
Il est impossible de fournir une réponse à ta question

Pour les références circulaire, pense que uses peut-être dans interface et implementation, cela résoud généralement ce type de problème c'est même écrit dans la documentation Ajout de fiches - Références circulaires d'unités

[Gilbert Geyer]

Bonjour,

A noter qu'on a également le cas n° 4 où la "globalité" est restreinte et limitée aux seules routines de Form1 situées après l'emplacement de la déclaration de mavariable :

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
unit Unit1;

interface

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

type
  TForm1 = class(TForm)
  private
     { Déclarations privées }
  public
     { Déclarations publiques }
  end;

var
  Form1: TForm1;
 
implementation

{$R *.dfm}

procedure Tagada;
begin     ...
end;

...
...
var mavariable: integer;

procedure TrcucMuche;
begin       ....
              z:=F(mavariable);
              ... 
end;

procedure Tralalalere;
begin       ....
              q:=G(mavariable);
              ... 
end;

end.

Par contre le cas n°3 avec regroupement dans une unité ne contenant que les constantes et variables est préférable pour le cas où celles-ci sont réellement utilisées par la quasi-tolalité des autres unités.
Pour les constantes ceci ne pose aucun problème puisqu'elles sont constantes. Mais pour les variables globales se méfier car dans certaines routines elles peuvent être temporairement considérées comme constantes dans une boucle et si dans la même boucle une instruction appelle une routine d'une autre unité qui en modifie sa valeur on galère pour trouver la cause du bug.
En conséquence de quoi, je préfère pour ma part une unité qui ne regroupe que les constantes ainsi que des routines qui sont utilisées par la quasi-totalité des autres unités et qui ne modifient aucune variable globale...

A+.

EDIT : Oups, ShaiLeTroll m'a pris de vitesse.

[looping]

Bonjour,

Merci à tous pour votre aide

Je vais donc prendre la solution d'une unité *.pas sans fiche dans laquelle je stockerais les variables


A+