Discussion :

[Jlmat]

bonjour,

Éternel débutant je suis, je récapitule comme toujours les bonnes pratiques...!
Je suis en train de réfléchir sur l'organisation de mes fichiers de code et plus précisément sur l'emplacement de mes déclarations de constantes ou de types.
En particulier pour tenir compte d'un temps de chargement et de niveau de charge de la mémoire centrale de l'ordinateur hôte.

Dans cet esprit, je me posais la question de savoir qu'elle était l'utilité de déclarer des constantes ou des types dans un fichier xxx.inc plutôt que dans l'interface d'une unité .pas.
Personnellement, je préfère tout avoir en interface d'une unité!

Qu'en pensez-vous?

merci pour vos lumières éclairantes

[SergioMaster]

Bonjour,

c'est tout à fait le genre de cas où je suis partagé.
Dans une unité oui, c'est plus pratique à la lecture et donc quelque part plus facile à la maintenance de l'unité.
Mais dans le cas d'une application, donc plusieurs unités potentiellement réutilisables dans d'autres programmes le fichier à inclure c'est vraiment top.

Exemples : J'ai tendance à utiliser un fichier inc pour les informations auteur, licence, etc. plutôt que de les mettre dans les options du projet (moins portable vers les OS non windows)
Pour la localisation, pour l'instant, je préfère mettre les constantes à l'unité ce qui me semble plus facile quand il s'agit de se lancer dans la traduction.
(c'est les seuls exemples qui me viennent à l'instant, mais j'ai certainement d'autres cas)

Ce qui ferait constantes "données" ou à ne surtout pas localiser (SQL par exemple) en fichier .inc , constantes concernant l'IHM (localisables) dans le .pas
et, à cela, il faut ajouter les possibilités d'utiliser le fichier ressource

Donc réponse de Normand, peut-être d'autres intervenants finiront-ils par faire pencher ma balance.

[Paul TOTH]

bonjour,

Éternel débutant je suis, je récapitule comme toujours les bonnes pratiques...!
Je suis en train de réfléchir sur l'organisation de mes fichiers de code et plus précisément sur l'emplacement de mes déclarations de constantes ou de types.
En particulier pour tenir compte d'un temps de chargement et de niveau de charge de la mémoire centrale de l'ordinateur hôte.

voilà de nobles objectifs, mais tu parles des performances de l'IDE ou de l'application compilée ?
dans le premier cas, à moins de travailleur sur une machine à très faibles performances tu ne verras pas la différence, dans le second cas ça ne fait aucune différence

Dans cet esprit, je me posais la question de savoir qu'elle était l'utilité de déclarer des constantes ou des types dans un fichier xxx.inc plutôt que dans l'interface d'une unité .pas.
Personnellement, je préfère tout avoir en interface d'une unité!

Qu'en pensez-vous?

merci pour vos lumières éclairantes

les fichiers INC sont généralement utilisés pour inclure la même information dans différentes unités sans qu'il soit possible de le faire par un "uses". cela concerne très peu d'informations en fait
par exemple, les {$DEFINE xxx} - sauf à les définir dans les options du projet - n'ont pas une portée globale, donc il est courant de les mettre dans un INC qui est inclut dans chaque unité.

j'utilise parfois des INC pour mettre du code quand je traduis un projet C/C++ car c'est souvent plus simple à organiser dans un premier temps en collant à la logique C qui ne fonctionne que par inclusion. je crée alors l'équivalent du .h avec des "forward" sur les fonction et un second qui correspond au .c...cela permet de contourner les éventuels référence circulaires propres au Pascal.

Après, l'IDE n'est pas très adapté pour travailler sur du code dans les includes, la navigation fonctionne mal notamment.

Pour en revenir aux constantes et les types, je ne les places dans une unité à part que si elles sont très verbeuses et nuisent à la lisibilité du code, exemple https://github.com/tothpaul/TokyoScr...t.Keywords.pas

[Jlmat]

merci à Sergio et à Paul pour leurs réponses...

voilà de nobles objectifs, mais tu parles des performances de l'IDE ou de l'application compilée ?

Je parle de la version complilée! donc aucune différence, je suppose que le fichier .inc est incorporé et optimisé effectivement...

Sur le lien que tu donnes Paul, est-ce qu'il faut s'inscrire pour voir keywords.pas car je ne trouve pas dans les topic!

Bon finalement, à part le fait effectivement d'une réutilisation de données d'une application à une autre ou de facilité pour des traductions, il n'y a pas de grandes différences...
personnellement, je me suis fait des bibliothèques de procédures par type d'utilisation que j'enrichi au fur et à mesure et que je maintiens : gestion de fichiers, système, calcul et formes graphiques, contrôles de saisies etc...

J'ai parfois des scrupules à réutiliser ces bibliothèques de fonctions car je ne sais pas si le compilateur recense systématiquement toutes les adresses de fonctions et variables de l'interface ou seulement de celles qui sont utilisées, ce qui serait logique;

[Paul TOTH]

merci à Sergio et à Paul pour leurs réponses...



Je parle de la version complilée! donc aucune différence, je suppose que le fichier .inc est incorporé et optimisé effectivement...

Sur le lien que tu donnes Paul, est-ce qu'il faut s'inscrire pour voir keywords.pas car je ne trouve pas dans les topic!

si j'ouvre l'URL dans un session private de Chrome il m'indique "Join GitHub today" mais le source est juste en dessous.

Bon finalement, à part le fait effectivement d'une réutilisation de données d'une application à une autre ou de facilité pour des traductions, il n'y a pas de grandes différences...
personnellement, je me suis fait des bibliothèques de procédures par type d'utilisation que j'enrichi au fur et à mesure et que je maintiens : gestion de fichiers, système, calcul et formes graphiques, contrôles de saisies etc...

J'ai parfois des scrupules à réutiliser ces bibliothèques de fonctions car je ne sais pas si le compilateur recense systématiquement toutes les adresses de fonctions et variables de l'interface ou seulement de celles qui sont utilisées, ce qui serait logique;

oui tu peux faire des unités aussi longue que tu veux, le compilateur ne conservera que le code utile à l'application compilée. Attention, si tu places du code dans la section "initialization" celui-ci (et ses dépendances) sera toujours inclus. De même toute ressource {$R xxx} sera forcément ajoutée.

[Jlmat]

Merci Paul, c'est noté
Par contre je n'ai pas réussi à télécharger la source Keywords.pas et l'exemple de projet qui va avec parce qu'il faut s'inscrire, ce qu'il me refuse, je sais pas pourquoi...
C'est pas grave, tu as déjà bien répondu à ma question de départ
jlmat