Programmes et unités
Les unités ont été introduite à partir du Turbo Pascal 4 avec les mots réservés UNIT, USES, INTERFACE et IMPLEMENTATION. Il est ainsi disponible dans la version Turbo Pascal 4, Turbo Pascal 5, Turbo Pascal 5.5, Turbo Pascal 6 et Turbo Pascal 7, tandis que dans les versions antérieur Turbo Pascal 1, Turbo Pascal 2 et Turbo Pascal 3, il ne supportait pas les unités et il fallait mettre tout le code dans le programme principale. L'avantage premier de l'introduction des unités (UNIT), en dehors du fait que le programme est mieux structurés, c'est la capacité de dépassé la limite de 64 Ko de code pour un programme. Le deuxième avantage réside dans le fait qu'on peut partager les mêmes unités dans différents programmes.
A partir du Turbo Pascal 4, un programme Turbo Pascal se compose d'un entête de programme, d'une clause USES facultative et d'un bloc :
L'entête du programme
L'entête du programme précise le nom du programme et ses paramètres :
Si un entête de programme est présent, le compilateur l'ignore.
La clause USES
La clause Uses identifie toutes les unités utilisées par le programme :
L'unité System est toujours utilisée automatiquement. Le système implémente toutes les procédures et fonctions d'exécution de bas niveau pour prendre en charge des fonctionnalités telles que l'entrée et la sortie de fichiers (entrée/sortie), la gestion des chaînes de caractères, la virgule flottante, l'allocation de mémoire dynamique,...
Outre System, le Turbo Pascal implémente de nombreuses unités standard, telles que Dos et Crt. Ceux-ci ne sont pas utilisés automatiquement ; vous devez les inclure dans votre clause USES. Par exemple :
L'ordre des unités listées dans la clause USES détermine l'ordre de leur initialisation. Pour trouver le fichier d'unité contenant une unité compilée, le compilateur tronque le nom d'unité répertorié dans la clause USES aux huit premiers caractères et ajoute l'extension de fichier «.TPU» ou («.TPP» en mode protégé, «.TPW» en mode Windows). Par exemple, une unité nommée MathFunctions sera entreposée dans un fichier nommé MATHFUNC.TPU. Même si le nom de fichier est tronqué, une clause USES doit toujours spécifier l'identificateur d'unité complet.
Syntaxe des unités
Les unités sont la base de la programmation modulaire en Turbo Pascal. Ils sont utilisés pour créer des bibliothèques que vous pouvez inclure dans divers programmes sans rendre le code source disponible, et pour diviser de gros programmes en modules logiquement liés.
L'entête de l'unité
L'entête de l'unité spécifie le nom de l'unité :
Le nom de l'unité est utilisé pour faire référence à l'unité dans une clause USES. Le nom doit être unique : Deux unités portant le même nom ne peuvent pas être utilisées en même temps. Le nom du fichier source et du fichier binaire d'une unité doit être le même que l'identificateur de l'unité, tronqué aux huit premiers caractères. Si ce n'est pas le cas, le compilateur ne peut pas trouver le fichier source et/ou binaire lors de la compilation d'un programme ou d'une unité utilisant l'unité.
La partie interface
La partie interface déclare des constantes, des types, des variables, des procédures et des fonctions étant publics ; c'est-à-dire disponible pour l'hôte (le programme ou l'unité utilisant l'unité). L'hôte peut accéder à ces entités comme si elles étaient déclarées dans un bloc enfermant l'hôte.
À moins qu'une procédure ou une fonction ne soit en ligne, la partie interface ne répertorie que l'en-tête de la procédure ou de la fonction. Le bloc de la procédure ou de la fonction suit dans la partie implémentation.
La partie implémentation
La partie implémentation définit le bloc de toutes les procédures et fonctions publiques. De plus, il déclare des constantes, des types, des variables, des procédures et des fonctions étant privés ; c'est-à-dire qu'ils ne sont pas disponibles pour l'hôte.
Les déclarations de procédure et de fonction dans la partie interface sont similaires aux déclarations FORWARD, bien que la directive FORWARD ne soit pas spécifiée. Par conséquent, ces procédures et fonctions peuvent être définies et référencées dans n'importe quel ordre dans la partie implémentation.
Les entêtes de procédure et de fonction peuvent être dupliqués à partir de la partie interface. Vous n'avez pas besoin de spécifier la liste des paramètres formels. Si vous le faites, le compilateur émettra une erreur de compilation si les déclarations d'interface et d'implémentation ne correspondent pas.
La partie initialisation
La partie initialisation est la dernière partie d'une unité. Il se compose soit du mot réservé END (auquel cas l'unité n'a pas de code d'initialisation) soit d'une partie instruction à exécuter pour initialiser l'unité.
Les parties d'initialisation des unités utilisées par un programme sont exécutées dans le même ordre que les unités apparaissent dans la clause USES.
Références unitaires indirectes
La clause USES d'un module (programme ou unité) n'a besoin que de nommer les unités utilisées directement par ce module. Considérer ce qui suit :
Ensuite, la définition de l'unité Unit2 :
Enfin, la définition de l'unité Unit1 :
Unit2 dépend directement de Unit1 et Prog est directement dépendant de Unit2. De plus, Prog dépend indirectement de Unit1 (via Unit2), même si aucun des identificateurs déclarés dans Unit1 n'est disponible pour Prog.
Pour compiler un module, le compilateur doit être capable de localiser toutes les unités dont le module dépend, directement ou indirectement. Ainsi, pour compiler Prog, le compilateur doit être capable de localiser à la fois Unit1 et Unit2, ou une erreur se produit.
Lorsque des modifications sont apportées à la partie interface d'une unité, les autres unités utilisant l'unité doivent être recompilées. Si vous utilisez Make ou Build, le compilateur le fait automatiquement pour vous. Si des modifications sont apportées uniquement à l'implémentation ou à la partie d'initialisation, les autres unités utilisant l'unité n'ont pas besoin d'être recompilées. Dans l'exemple précédent, si la partie interface de Unit1 est modifiée (par exemple, c=2) Unit2 doit être recompilée, mais la modification de la partie implémentation (par exemple, d = 1) ne nécessite pas de recompiler Unit2.
Le Turbo Pascal peut dire quand la partie interface d'une unité a changé en calculant un numéro de version d'unité lorsque l'unité est compilée. Dans l'exemple précédent, lorsque Unit2 est compilé, le numéro de version actuel d'Unit1 est enregistré dans la version compilée de Unit2. Lorsque Prog est compilé, le numéro de version d'Unit1 est comparé au numéro de version entreposé dans Unit2. Si les numéros de version ne correspondent pas (indiquant qu'un changement a été apporté dans la partie interface d'Unit1 car Unit2 a été compilé), le compilateur signale une erreur ou recompile Unit2, selon le mode de compilation.
Références des unités circulaires
Si vous placez une clause USES dans la section d'implémentation d'une unité, vous masquez les détails internes de l'unité référencée dans la clause USES ; l'unité référencée est privée et n'est pas disponible pour le programme ou l'unité utilisant l'unité dans laquelle elle est référencée. Vous pouvez utiliser cette technique pour construire des unités interdépendantes.
Remarquez, que du Turbo Pascal 4 au Turbo Pascal 6, les unités ne pouvait pas être circulaire dans la section IMPLEMENTATION. Il s'agit d'une nouveauté mise en oeuvre dans le Turbo Pascal 7.
Le programme suivant montre comment deux unités peuvent «s'utiliser» l'un l'autre :
Le programme principal, Circular, utilise une unité nommée Display :
- Unit Display;
-
- { Contient une routine d'affichage vidéo simple }
-
- INTERFACE
-
- Procedure WriteXY(X,Y:Integer;Message:String);
-
- IMPLEMENTATION
-
- Uses Crt,Error;
-
- Procedure WriteXY(X,Y:Integer;Message:String);Begin
- If(X in [1..80])and(Y in [1..25])Then Begin
- GoToXY(X, Y);
- Write(Message);
- End
- Else
- ShowError('Coordonnées de WriteXY invalide');
- End;
-
- END.
L'unité Display déclare la procédure WriteXY dans sa section interface. La procédure WriteXY écrit un message à l'écran. Le programme Circular précise le contenu et la position à l'écran du message dans les paramètres passés à WriteXY. Si les coordonnées de l'écran ne sont pas à l'écran, WriteXY appelle la procédure ShowError. Le ShowError n'est pas dans l'unité Display, mais dans une autre unité, Error, référencée dans la section Uses de la section d'implémentation de l'unité d'affichage. C'est l'unité Error :
L'unité Error est quelque peu inhabituelle : sa seule procédure déclarée, ShowError, utilise la procédure WriteXY déclarée dans l'unité Display, l'unité appelant la procédure ShowError. La clause USES dans les sections d'implémentation des unités Display et Error se réfèrent l'une à l'autre. Ceci est possible car Turbo Pascal peut compiler des sections d'interface complètes pour les deux. Le compilateur accepte une référence à une unité partiellement compilée dans la section d'implémentation d'une autre unité, tant que la section d'interface d'aucune unité ne dépend de l'autre. Par conséquent, les unités suivent les règles strictes de Pascal pour l'ordre de déclaration. Si les sections d'interface sont interdépendantes, vous obtenez une erreur de référence d'unité circulaire.
Si vous souhaitez modifier les procédures WriteXY et ShowError pour prendre un paramètre supplémentaire spécifiant une fenêtre rectangulaire à l'écran, vous pouvez écrire ceci :
Ces procédures sont déclarées dans les sections d'interface des différentes unités. Étant donné que les deux doivent utiliser le type WindRec, WindRec ne peut être déclaré dans aucune des sections d'interface, ce qui les ferait dépendre l'un de l'autre. La solution est de créer une troisième unité ne contenant que la définition de l'enregistrement de fenêtre :
Vous pouvez maintenant ajouter WindData à la clause USES dans les sections interface des unités Display et Error. Ces deux unités peuvent utiliser le nouveau type d'enregistrement, mais Display et Error se réfèrent toujours l'un à l'autre uniquement dans leurs sections d'implémentation respectives. Les unités interdépendantes peuvent être utiles dans des situations particulières, mais utilisez-les judicieusement. Si vous les utilisez lorsqu'ils ne sont pas nécessaires, ils peuvent rendre votre programme plus difficile à maintenir et plus susceptible aux erreurs.