Discussion :

[wiwaxia]

Bonjour,

Je suis actuellement bloqué dans l'écriture d'un programme Turbo-Pascal, comportant l'enchaînement suivant de procédures :
P1 ---> P2 ---> P3 ---> Retour; FORWARD;
Il m'est impossible de transférer dans une unité appropriée P1 et P2, pourtant très volumineuses. Comment procéder ?

L'appel de P3 correspond à un cas rare mais non exclu interdisant la poursuite des calculs, et permet de revenir au début du programme en évitant son plantage. Le contenu de P3 pourrait évidemment se terminer par l'instruction <Halt>, ce qui arrêterait tout.

J'aimerais connaître les solutions, s'il en existe. Merci de m'indiquer des pistes.

[mick605]

Salut

Sans nous en dire plus, difficile de savoir ce qui ne va pas ... Donne nous ton code pour voir. A mon avis, ça vient d'un problème de déclaration dans tes unités.

Par contre, je vois 2 problèmes de conception dans ton programme :
1) En général, une procédure ne doit pas être volumineuse, elle doit être découpée en plusieurs procedures
2) Utiliser la fonction Halt est, je pense, une mauvaise idée. Il vaudrait mieux gérer soi-même l’arrêt du programme.

Enfin, il serait peut être plus judicieux de passer sous un compilateur plus récent, comme FreePascal avec Lazarus ...

Bonne chance

[wiwaxia]

Je vous remercie des remarques que vous avez exprimées.

Le programme principal, après l'initialisation du mode graphique et de quelques variables, se réduit à l'appel de la procédure <Choix>:

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
 VAR Depart: BOOLEAN;
 
 PROCEDURE Choix(VAR Depart: BOOLEAN);
    VAR Touche: CHAR; CodeT: LONGINT;
    BEGIN
       REPEAT
         IF Depart THEN BEGIN
		        Depart:= False; Touche:= '1';
		        Menu; Ag;       P0
                               END
                       ELSE Touche:= ReadKey;
         CASE Touche OF  #08: Menu; '0': P0;
                                 '1': Pa; '2': Pb  END   { présentation simplifiée }
       UNTIL Touche=#27;
      Ag
   END;
 
 PROCEDURE Retour;
    BEGIN
      Menu; Choix(Depart)
    END;
 
 BEGIN
   AppelModGraph(MdGr, ModeTexte); InitCentreRayon(Xcen, Ycen, Rayon);
   Depart:= True; Choix(Depart);        CloseGraph
 END.

Je cherche à sortir de l'impasse dans laquelle me conduit l'obligation de la référence en amont: si je met <P1> dans l'unité <U>, le compilateur exige d'y trouver <P2>, puis <P3>, puis <Retour> ... et là bien sûr, rien ne va plus. Y a-t-il un moyen d'éviter l'arrêt du programme au niveau de <P3> ?
Il y a quatre boucles imbriquées, dont 3 dans <P1> et une dans <P2>; l'appel de P3 correspond à la nécessité d'arrêter les calculs dans un cas très particulier.
Cette partie du programme inventorie les faces et les arêtes d'un polyèdre dont les (n) sommets sont situés sur une sphère; elle fonctionne correctement pour n<=100, mais le texte est assez long, malgré l'utilisation d'une huitaine d'unités.

[M.Dlb]

Il devrait y avoir une condition qui fait que toutes les boucles imbriquées sont arretées, je pense que tu connais déjà cette condition, qui correspond à l'appel à P3. Mais plutôt d'appeler P3, il faut "dépiler" ou sortir proprement de chaqe boucle imbriquée, même si c'est plus complexe à programmer. Regarder aussi du côté de l'instruction break qui peut être très pratique, de même que exit.

[mick605]

Tout a fait d'accord avec wormful.

Un autre conseil, dans ton programme, tu as une variable Depart globale, et un argument Depart. Il serait judicieux d'en renommer une, pour éviter les problèmes...

[droggo]

Soe,

Tout a fait d'accord avec wormful.

Un autre conseil, dans ton programme, tu as une variable Depart globale, et un argument Depart. Il serait judicieux d'en renommer une, pour éviter les problèmes...

Et mieux encore, éviter les variables globales.

(Je n'ai pas lu le code, et je ne sais donc pas quel en est l'usage, c'est seulement une bonne habitude à prendre [ou plus exactement, une mauvaise habitude à perdre ])

[wiwaxia]

Un grand merci à wormful_sickfoot et mick605 pour les informations données; l'instruction <break> m'avait totalement échappé; je pense qu'elle me permettra d'éviter l'appel de <FORWARD>, et ainsi de transférer 3 pages d'écran dans une unité.
Je donne le même nom à la variable et à l'argument lorsqu'il n'intervient par la suite qu'une instruction d'affectation; l'ambiguïté de la notation peut effectivement jouer de mauvais tours, si l'on s'avise par la suite de modifier le programme, et c'est sans doute une pratique à éviter.
La remarque de droggo, lue à l'instant, m'intrigue un peu: il faut bien un minimum de variables glogales, quoiqu'elles soient encombrantes, pour piloter le programme et contenir les résultats des calculs ... s'il y a de ce côté-là des astuces, je veux bien les connaître.
Le programme concerné (et actuellement en chantier) utilise les variables globales suivantes: - depart (BOOLEAN);
- Ns, Nf, Na (WORD): nombres de sommets, de faces et d'arêtes
- LstP, LstN: listes de N et 2N vecteurs 3d pour les positions des sommets et les normales aux faces;
- LstF: liste de 2N "faces" énumérant les sommets du polygone (8 WORD disponibles)
- LsrA: liste de 3N "arêtes" de type RECORD comportant 4 word (indices des sommets et des normales aux faces adjacentes) et 2 réels (longueur de l'arête et angle des 2 normales).
Ces tableaux sont, en raison de leur taille, définis dans une unité séparée. N (ici égal à 100) représente le nombre maximal de sommets, puisque l'on a
Nf <= 2*Ns - 4 < 2*N et Na <= 3*Ns - 6 < 3*N.

Cordiales salutations à tous les trois.

[M.Dlb]

Concernant les variables globales et les paramètres... On dit souvent qu'il faut éviter les variables globales, et c'est vrai pour certains cas, en particulier les calculs... Mais les variables globales peuvent être utilisées pour donner l'état d'un élément global à l'application (typiquement, si l'application doit s’arrêter ou pas, ou si un composant un disponible ou non, etc...)

En ce qui concerne les paramètres fournies à une procédure/fonction, je me demande toujours de quoi a besoin une fonction en entrée pour effectuer le travail unitaire que je programme. Et je m'arrange toujours pour que les paramètres que je lui passe lui soient totalement suffisants, et qu'elle n'aille pas chercher de variable globale... Si la fonction a besoin d'une variable globale, je la passe quand même en paramètre, pour être sûr de manipuler la bonne variable

[Paul TOTH]

1) qu'appelles tu FORWARD, car ce mot clé Pascal a une signification mais je ne vois pas le rapport avec ton problème

2) les variables globales ont une raison d'être, il est dommage de s'en priver quand elles remplissent leur fonction. Notamment un objet Singleton sera référencé par une variable globale...mais je ne trouve pas qu'il soit forcément nécessaire de regrouper plusieurs variables globales dans un Singleton justement.

exemple de Singleton

Code :

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

1
2
3
4
5
6
7
8
9
 
type
  TApplication = class
    Running: Boolean;
    class function ExeName: string;
  end;
 
var
  Application: TApplication;

exemple sans Singleton qu'on pourra placer dans une unité "Application" qui permettra l'écriture "Application.ExeName" sans que ce soit un objet.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
unit Application;
 
interface
 
var 
  Running: Boolean;
 
function ExeName: string;
 
implementation
...

[wiwaxia]

A Paul TOTH.

Bonjour, je reviens au forum après une absence.
Merci pour les indications de code apportées.
Pour répondre précisément à ton intervention:
1) Je cherchais le moyen de rassembler des procédures dans une unité, alors que les appels successifs devaient conduire, dans un cas particulier, à un retour en début de programme (voir mes deux premiers messages). On m'a apporté des informations, et l'échange a dérivé sur l'emploi des variables.

2) Je suppose que le recours au singleton apppartient à Delphi, que je ne pratique pas.
Le second exemple m'intrigue

Code :

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

1
2
3
4
5
6
7
8
9
10
unit Application;
 
interface
 
var   Running: Boolean;
 
function ExeName: string;
 
implementation
...

car il autorise l'emploi d'une écriture

Code :

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

Application.ExeName

habituellement résevée aux enregistrements et aux objets. Où pourrais-je trouver des indications sur ce sujet ? J'utilise sans problème les enregistrements et les unités, mais pas les objets.
Cordialement,
Wiwaxia.

L'étude de la structure d'un polyèdre a pour donnée centrale la liste des arêtes, qui établit le lien entre deux couples de vecteurs, les 2 sommets concernés et les normales aux 2 faces adjacentes. Le programme devient vraiment très lourd dès qu'il s'agit d'énumérer les cycles (listes ordonnées des sommets consécutifs reliés par une arête à un sommet donné, ou des faces consécutives adjacentes à une face donnée). Ces deux problèmes relèvent du même algorithme, et le recours aux pointeurs serait peut-être pertinent (mais je les maîtrise mal).

[Paul TOTH]

je n'ai pas tout compris, mais quoi qu'il en soit, les Unité Pascal constitues un espace de nommage au même titre que les enregistrements et les objets.

généralement on ne spécifie pas le nom de l'unité d'un symbole auquel on fait référence, mais il est possible et parfois nécessaire de le faire. Notamment si deux unités différentes déclarent des symboles homonymes, le seul moyen d'adresser les deux et d'utilise le nom d'unité.

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
 
unit unit1;
interface
var
  test: Integer;
implementation
end.
 
//----
unit unit2;
interface
var
  test: Integer;
implementation
end.
 
//---
program Projet1;
uses
  Unit1, Unit2;
begin
  test := 1; // c'est Unit2.Test qui est affecté
  Unit1.test := 2; // seul moyen d'atteindre Unit1.test
end.

[Roland Chastain]

Où pourrais-je trouver des indications sur ce sujet ? J'utilise sans problème les enregistrements et les unités, mais pas les objets.

C'est vrai qu'on ne rencontre pas très souvent le type Object dans les exemples pour Turbo Pascal. Cependant il est simple à utiliser :

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
 
(* Turbo Pascal *)
 
(* Emploi du type Object *)
 
program exemple;
 
type
  tMessage = object
               text: string;
               procedure initialise (const s: string);
               procedure affiche;
             end;
 
procedure tMessage.initialise (const s: string);
begin
  self.text := s;
  (*text := s;*)
end;
 
procedure tMessage.affiche;
begin
  writeLn(self.text);
  (*writeLn(text);*)
end;
 
var
  msg1, msg2: tMessage;
 
begin
  msg1.initialise('Bonjour !');
  msg1.affiche;
  msg2.initialise('Appuyez sur une touche !');
  msg2.affiche;
  readLn;
end.

Soit dit en passant, pour compiler ce programme sous Delphi 6 par exemple, comme je viens de le faire, il suffit d'ajouter cette directive :

Code :

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

1
2
3
program exemple;
 
{$APPTYPE CONSOLE}

et de changer l'extension du fichier de .pas en .dpr. En fait le seul problème dans Delphi c'est le nom.

[wiwaxia]

Salut,
J'ai pris bonne note des remarques concernant les unités et les objets, d'autant plus que le programme sur lequel je travaille (en reprenant une ancienne version) s'allonge rapidement, et se prête à de nombreuses variantes.