Discussion :

[rvzip64]

Salut tout le monde, est ce que quelqu un aurait le nom d un logiciel parformant qui permet de nettoyer les unitées inutilies dans les uses ??

[droggo]

Jai,

Tu en as combien de milliers pour avoir besoin d'un outil ?

Le meilleur, est de ne les mettre qu'en cas de réel besoin, et de les enlever immédiatement quand il n'y en a plus besoin en cas d'évolution du logiciel.

[rvzip64]

Le probleme c'est que quand tu écris un logiciel tu n'es pas forcement tout seul à y travailler dessus. Alors peut etre qu'un outil te semble exagéré, mais je te promet que cela a un réel interet.

Merci quand meme

[droggo]

Seul ou à 2000, si tout le monde suit le même principe, ça ne posera pas de problème.

En groupe, il y a forcément des règles à respecter, sinon je vous plains côté foutoir.

Et ce n'est qu'une règle de plus, pas vraiment méchante, hein.


Non, je ne connais pas d'outil pour faire ça. Un exercice pourrait être d'en développer un ?

[sjrd]

J'ai ouï dire que cela existait dans la suite d'experts GExperts.

[TryExceptEnd]

Voici un outil en freeware :
http://www.peganza.com/#ICARUS

[Clorish]

Boah moi je supprime tous les uses et je reecrit ceux qui manquent a la compil
Apres ... suffit de parcourir methodiquement les unitees

Par contre, quel est l'interet de les supprimer vu que l'optimisation a la compilation n'importe que le code effectif. Donc toute unitee importee mais non utilisée ne sera pas presente dans l'executable.
Enfin ca fait quand meme plus propre.

Je met juste un bemol sur le point precedent, du fait que certaines unitees effectuent du code dans la section Initialization.
Celles ci doivent etre utilisées avec attention

[BRODU]

Bonjour,

Personnellement j'utilise cnWizards de cnPack. Il s'agit d'un produit similaire à GExperts, mais qui me paraît plus complet. Paour ma part, il a remplacer gExperts.

Dans ce produit, il existe un module qui permet de supprimer les unités non utilisées dans les uses.

Mais en fait, il apporte beaucoup plus et aujourd'hui, j'aurais beaucoup de difficultés à m'en passer.

Tu le trouveras en version cnWizards 0.8.2.322_RC1 à l'adresse suivante :

http://www.cnpack.org/index.php?lang=en

Ce produit est toujours en évolution, il est cependant très stable en cette version.

Cordialement

[rvzip64]

Seul ou à 2000, si tout le monde suit le même principe, ça ne posera pas de problème.

En groupe, il y a forcément des règles à respecter, sinon je vous plains côté foutoir.

Et ce n'est qu'une règle de plus, pas vraiment méchante, hein.

ARF .... je suis d acord, mais l'erreur est humaine et un oubli peut vite arrivé dans ce genre de situation. De plus un outil permet de gagner un peu de temps

[LadyWasky]

Je confirme ce que te dis BRODU, il existe un tel utilitaire dans les cnPacks.

Sinon, quand tu supprimes tes unités à la main, et que tu re-compiles, Delphi te remet dans le uses les unités dont il a besoin, enfin celles utilisées pour les composants visuels que tu as placées sur la fiche.

Les unités du style strutils sont à rajouter à la main étant donné qu'elle ne contiennent pas le code de composants VCL.

[CapJack]

Rappelons quand même un principe que personne n'a pensé à rappeler : un compilateur digne de ce nom n'incorpore dans l'exécutable final que ce qui est utile ! Ceci s'applique d'ailleurs aux unités entières, mais aussi aux procédures et fonctions individuelles à l'intérieur d'une unité : seul le code effectivement utilisé est incorporé dans l'exécutable final.

Alors, à quoi bon "purifier" les clauses uses ? Ça ne sert strictement à rien, à part perdre du temps. Je sais bien que le refactoring est à la mode, et que les dévelopeurs de tels outils doivent gagner leur croûte, mais n'utilisons ce genre d'outil que quand c'est vraiment nécessaire (consolidation avec try..except, collecte de chaînes pour une localisation, etc).

Dans le cas présent, c'est vraiment une perte de temps.


Petite expérience : compilez une application vide.

Clause par défaut :

Code :

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

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

Résulat pour l'exécutable (Delphi 2005) : 375808 octets


Purifions la clause uses, qui pour une appli vide n'a besoin que de Forms :

Code :

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

uses Forms;

Résulat pour l'exécutable (Delphi 2005) : 375808 octets

[sjrd]

Ce que tu dis n'a que peu de sens, CapJack. Et je peux démonter ton argument en trois secondes.

Dans Forms.pas, tu as :

Code :

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

1
2
uses Messages, Windows, SysUtils, Classes, Graphics, Menus, Controls, Imm,
  ActnList, MultiMon, HelpIntfs;

Et récursivement tu en as encore plus ! Quand tu ne mets que Forms.pas, il met de toutes façons toutes ces autres unités.

Ensuite, comme l'a fait remarquer Clorish je crois, la simple présence de codes d'initialisation et de finalisation dans une unité lui donne le droit d'exister dès qu'elle se trouve quelque part dans les uses. Sinon comment fonctionnerait XPMan par exemple ?

Ces considérations de liaison intelligente ne sont en général pas vraie. Seulement pour les routines qui ne sont effectivement jamais appelées. Mais comme la plupart des routines sont appelées par les méthodes de classes, qui, dû à leur enchevêtrement complexe, sont presque toujours liées, même les routines sont souvent liées.

Si on peut se passer de certains uses, cela fait quand même une différence.

Aussi, c'est beaucoup plus clair à la lecture du code source, si seules les unités nécessaires sont utilisées. Moi je pousse même le bouchon jusqu'à les mettre dans un ordre habituel.

[CapJack]

Je retiens ton argument par rapport au croisement des unités. C'est vrai que mon exemple n'est pas très approfondi, mais c'était juste pour expliquer.

Quant à l'incorporation systématique des unités ayant un bloc initialization...finalization, en es-tu vraiment certain ? XPMan est incorporé parce qu'il modifie un certain type de ressources, et que ce type de modification est validée (car l'OS est censé y faire référence).

Mais quid d'une unité dont la clause init ne modifierait qu'un jeu de variables qui ne sont référencées nulle part ? Le compilateur, surtout dans ses versions récentes, est bien plus intelligent que tu ne sembles le croire, et je le prouve :

à mon projet vide précédent, j'ajoute une 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
unit Unit2;
 
interface uses Dialogs;
 
implementation
 
var A : Integer;
    B : Single;
    C : Double;
    D : string;
 
initialization
 
 A := 1254; // valeur jamais utilisée
 B := 3.52; // valeur jamais utilisée
 C := 78.5214; // valeur jamais utilisée
 D := 'bonjour'; // valeur jamais utilisée
 
end.

J'ajoute Unit2 dans la clause uses de la fiche, je compile et...

Résulat pour l'exécutable (Delphi 2005) : 375808 octets, autrement dit, pas un octet de plus !

Par contre, dès que j'ajoute ShowMessage(D) à la fin de la séquence d'initialisation, on passe à 402432 octets.

Es-tu toujours convaincu que ce que je dis n'"a pas de sens" ?

[sjrd]

Quant à l'incorporation systématique des unités ayant un bloc initialization...finalization, en es-tu vraiment certain ? XPMan est incorporé parce qu'il modifie un certain type de ressources, et que ce type de modification est validée (car l'OS est censé y faire référence).

Absolument certain. Je peux également citer les unités qui par leur simple présence, ressencent dans leur initialization une classe avec RegisterClass -> Toute la classe est liée, et avec elle il y a beaucoup de chances que le reste de l'unité y passe.

Mais quid d'une unité dont la clause init ne modifierait qu'un jeu de variables qui ne sont référencées nulle part ? Le compilateur, surtout dans ses versions récentes, est bien plus intelligent que tu ne sembles le croire, et je le prouve :

Certes, mais si tu mets tes variables dans la partie interface ?
En fait là le compilo remarque que ces variables ne sont jamais lues (il peut le faire car elles sont en implementation, donc "privées"). Il ne compile donc pas du tout les instructions qui les modifient. Du coup, il a une initialization qu'il ne compile donc pas non plus, et donc l'unité est vide -> qu'elle soit liée ou non, il n'y aura effectivement pas un octet de plus.

Es-tu toujours convaincu que ce que je dis n'"a pas de sens" ?

J'avais pris la précaution de dire "n'a que peu de sens". Je sais bien que les lieurs sont intelligents aujourd'hui. Mais en pratique il y a peu de choses qu'ils peuvent réellement faire
Quand on fait de petits tests comme cela, il faut toujours penser à vérifier le fait suivant : est-ce que ça arrive vraiment en pratique, le cas que je suis en train d'étudier ?

[CapJack]

Certes, mais si tu mets tes variables dans la partie interface ? En fait là le compilo remarque que ces variables ne sont jamais lues (il peut le faire car elles sont en implementation, donc "privées"). Il ne compile donc pas du tout les instructions qui les modifient. Du coup, il a une initialization qu'il ne compile donc pas non plus, et donc l'unité est vide -> qu'elle soit liée ou non, il n'y aura effectivement pas un octet de plus.

Je reconnais avoir encore été maladroit, mais si je déplace les variables dans la partie interface, ça ne change rien ! Et c'est normal !

Je crois vraiment que c'est toi qui interprètes mal les choses : tu ne fais référence qu'au compilateur, mais le comportement dont nous parlons ne concerne absolument pas le compilateur en lui-même, mais l'étape finale, le linker... c'est lui qui fait le tri au moment de l'assemblage final !

Une fois déplacées les variables dans la partie interface, le compilateur compile tout, évidemment, là nous sommes d'accord. Il compile tout le code, il stocke tous les symboles dans le .dcu. Pas de problème. Or nous ne parlons pas de la taille du .dcu, mais de l'exécutable final.

Et c'est au moment de l'assemblage final, au moment où le linker prend la main, que seuls les symboles et blocs de code référencés, quand bien même déjà compilés vont être incorporés à cette salade finale qu'est l'exécutable. C'est comme ça que ça marche ! L'optimisation en taille s'effectue en dernière étape, bien en aval de la compilation, et le format des unités Pascal est conçu pour... d'ailleurs ça marche même si l'on n'a pas le code source de l'unité.

[sjrd]

Je suis bien au courant de comment fonctionne un compilateur/linker, pour "travailler" dans le domaine.

Je dis seulement que, dans la plupart des cas réels, beaucoup des optimisations du linker sont : soit presque toujours faites, parce que ce sont des routines très rarement utilisées ; soit presque jamais faites, parce que l'enchevêtrement des appels de routines, des sections d'initialisation, et des informations de type à l'exécution, font qu'elles se recoupent toutes entre elles.

Donc le lieur est important. Sans ces optimisations, les exécutables seraient beaucoup plus gros. Mais ce serait leur base qui serait beaucoup plus grosse. Tout ce qu'on ajoute à une application VCL en plus de la fiche vierge fait rarement le poids face à ce qui existe dès le début.

[CapJack]

...donc, dans ce cas ça ne sert bien à rien de nettoyer les clauses uses.

CQFD.

[rvzip64]

Waow ... je demandais juste un outil pour me simplifier la tache MDR, je pensais pas que ça aller déchainer les passions

[TicTacToe]

Sinon il y a CNPack qui fonctionne assez bien la dessus, je l'ai utilisé pour certains projets.

Sinon, il y a bel et bien un avantage à ne laisser que les unités dont on a besoin, mis à part que cela peut prendre de la place et du traitement à cause des initialization et finalization. (les initialization peuvent même être dangereuse si non souhaitées dans certains cas!)

Un projet bouge et évolue, il se peut que l'on utilise un certains compo. pdt un temps, d'une certaine bibliotheque et qu'un beau jour on en change.
-> chercher/remplacer (car le replace component est rarement fiable en cas d'héritage de form) dans les sources + DFM
-> et là, si on laisse les uses comme ca parce finalement on s'en fout, on sera forcément embété un jour lors d'une réinstall de Delphi ou lors de la lecture du projet sur un autre poste (travail en équipe) (et ce remplacement de composant on l'aura forcément oublié, on sera plus dedans), les uses en trop seront très génant car les compos plus utilisés n'auront aucune raison d'avoir été installés.

De plus, on peut aussi tomber sur des unités circulaires à force de laisser trainer des unités en trop.

Bref, du ménage régulier dans les uses, n'est pas que esthétique, mais sert aussi à mieux comprendre un programme/ une unité à 1ere vue, et facilite sa maintenance. 6 mois après ne pas avoir à se dire, pourquoi cette unité est là ? sert-elle vraiment ?
Enfin, ce n'est que mon avis ^^

[rvzip64]

en tout cas merci a tous pour vos infos