Discussion :

[ZZZzzz2]

Bonjour,

J'ai un problème très simple dont voici un résumé :

J'ai deux unités : "UnitSub" et "UnitMain".
"UnitMain" possède une section d'initialisation créant un objet globale utilisé par un objet globale de "UnitSub" lui-même créé dans la section initialisation de cette dernière unité. Suis-je clair ?

Pour résumer :

Code :

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

1
2
3
4
5
6
7
Unit UnitMain;
 
initialization
   MainObj:= TMainObj.Create;
 
finalization
   MainObj.Free;

Pour résumer :

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
Unit UnitSub;
 
interface
 
uses 
   UnitMain;
 
constructor TSubObj.Create;
begin
   FData:= MainObj.Data;
end;
 
initialization
   SubObj:= TSubObj.Create;
 
finalization
   SubObj.Free;

Hors à l'exécution de mon programme je vérifie que la section initialization de "UnitSub" est appelé avant la section initialization de "UnitMain". Cela provoque donc une violation d'accès.

Pourquoi ne suis-je pas assuré que UnitMain soit initialisée avant puisqu'elle apparait dans la section "interface/uses" de mon unité "UnitSub" ??...

Cela ne me semble pas "normal" et m'ennuie beaucoup car remet en cause la logique que je pensais être la bonne jusqu'à présent, et du même coup l'intégrité de mes sections "initialization" et "finalization" de bon nombre de mes unités...

[Cl@udius]

Salut

Très certainement parce que dans la liste des uses de la section interface de UnitMain est inclus UnitSub.

L'appel aux sections initialization respecte l'ordre d'énumération des unités de la clause uses.

@+ Claudius

[ShaiLeTroll]

Tient lit ce sujet http://www.developpez.net/forums/d69...on-impossible/

j'ai découvert qu'en debug, l'ordre de initialization change, en fait l'unité en cours de modification est recompilée et relinkée avec les DCU des autres unités, du coup la séquence des uses n'est plus dans le même ordre, il faut utiliser une méthode de classe pour instancier la singleton et ne pas utiliser initialization pour un singletion

[Cl@udius]

Tient lit ce sujet http://www.developpez.net/forums/d69...on-impossible/

Je pense qu'il l'a déjà lu puisqu'il est l'auteur de cette discussion.

[ShaiLeTroll]

ça c'est Fort !
Ben, il n'a peut-être pas lu toute ma réponse à l'époque, puisque un peu hors-sujet

[ZZZzzz2]

Merci pour vos réponses,

En fait, étant donné que Delphi supporte des inter-dépendances entre unités vie les différentes sections "uses" (celle de "interface" et celle de "implementation") cela entraine forcément des cas où on ne peut déterminer précisément l'ordre d'initialisation des unités (à moins d'utiliser un outil comme "http://www.ciuly.com/tools/programming/pisa/index.html").

Ce n'est donc pas aussi simple que la logique bête qui était la mienne "si j'utilise une unité, elle sera initialisée avant moi". Ce n'est pas possible puisque justement Delphi permet l'interdépendance entre 2 unités, d'où mon cas de plantage...

Cela signifie qu'il faut prévoir le coup dans toutes les sections d'initialisation/finalization, ouch !!


Mon idée est d'écrire des méthodes globale "InitUnit" pour toutes mes unités possédant des sections "initialization", et d'appeler cette méthode à chaque fois dans cette section. Et lorsque je construit un objet globale je devrai vérifier que celui-ci n'est pas déjà instancié avant (il faut donc un "FreeAndNil" et non plus un ".Free" seulement). Et si sa construction dépend d'un autre objet globale d'une autre unité alors il faut appeler explicitement le "InitUnit" de cette unité.

C'est pas très clair, mais en gros j'aurai le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Unit UnitMain;
 
procedure InitUnit;
begin
   if ( not Assigned( MainObj ) ) then
      MainObj:= TMainObj.Create;
end;
 
initialization
   InitUnit;
 
finalization
   FreeAndNil( MainObj );

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 UnitSub;
 
interface
 
uses 
   UnitMain;
 
procedure InitUnit;
begin
   // Notre initialisation d'unité dépend de l'initialisation de l'unité "UnitMain"
   UnitMain.InitUnit;
 
   if ( not Assigned( SubObj ) ) then
      SubObj:= TSubObj.Create;
end;
 
constructor TSubObj.Create;
begin
   FData:= MainObj.Data;
end;
 
initialization
   InitUnit;
 
finalization
   FreeAndNil( SubObj );

Je pense que c'est le comportement à adopter pour s'assurer que les unités s'initialisent toujours correctement lorsqu'on a un projet trop complexe pour s'assurer du bon ordre d'utilisation de ses unités.


ShaiLeTroll> Oui j'ai remarqué aussi que l'ordre d'initialisation des unités changeait en mode debug après recompilation d'unité. C'est assez gênant car j'utilise des unités qui n'acceptent pas cela (FastMM par exemple).

[e-ric]

Salut à tous

Je connais une solution simple pour s'affranchir de la clause initialization s'il s'agit de créer un objet. En fait, je crée l'objet dès que j'en ai besoin en passant par une fonction, l'usage de la clause initialization n'est alors plus justifié. Ma solution est pratique si la construction de l'objet nécessite pas de paramètres, dans le cas contraire cela peut sans doute amener des complications.

En reprenant et adaptant ton 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
 
Unit UnitMain;
 
interface 
 
function MainObj: TMainObj;
 
implementation
 
var 
  FMainObj: TMainObj; 
 
function MainObj: TMainObj;
begin
  if not Assigned(FMainObj) then
    FMainObj := FMainObj.Create;
  Result := FMainObj;	
End;
 
initialization // sinon cela ne compile pas 
   ;           // sous Delphi 7 (version que j'utilise)
 
finalization
   FMainObj.Free; // Ca marche toujours
 
END.

Pour SubMain, Je reprend ton code, mais je n'ai pas tous les éléments pour le faire, il est peut-être incomplet.

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
 
Unit UnitSub;
 
interface
 
uses 
   UnitMain;
 
constructor TSubObj.Create;
begin
   FData:= MainObj.Data;
end;
 
initialization
   SubObj:= TSubObj.Create;
 
finalization
   SubObj.Free;

J'espère que ma solution te sera utile.

Cdlt

[ZZZzzz2]

Effectivement c'est une solution qui fonctionne très bien également, à la limite je dirai même qu'on pourrait pousser en ne créant plus d'objets dans "Initialization" et n'utilisant que des accès via fonction pour tous les objets dont on a une instance globale utilisé par d'autres unités. C'est une autre façon de faire, plus simple, mais qui peut-être moins optimale dans le cas d'utilisation de l'instance un très grand nombre de fois par seconde (boucle interne, etc...).
J'avoue que l'idée de passer par une fonction systématiquement me dérange un peu, mais c'est finalement plus propre. Alors j'hésite à changer...

[e-ric]

Salut

Pour le cas de la boucle, tu peux toujours affecter le résultat de la fonction (la référence de ton objet) dans une variable locale, 4 octets de plus dans la pile n'est pas catastrophique.

La méthode que je t'ai proposée suppose aussi que l'on ne souhaite pas changer la référence de l'objet (lecture seule).

Elle a cependant l'avantage de la facilité.

Cdlt

[ZZZzzz2]

Bien sur, mais il faut y penser (pour peu qu'on ait oublié ou qu'on fasse pas attention au fait que ce soit une fonction) ;-) !