Delphi: Quels sont les inconvénients des unités inutilisées énumérées dans la clause utilisée?

Delphi Smart Linker ignorera le code inutilisé afin que la présence de ces unités "supplémentaires" n'augmente pas la taille du programme compilé.

Voici quelques points que je reçois de Ce lien sur les inconvénients des unités inutilisées

1. Code de nettoyage à maintenir, pas besoin de vous embêter sur le code qui n'est pas utilisé
2. Code des sections d'initialisation et de finalisation dans des unités inutilisées n'est pas liée dans
3. La compilation fonctionne plus douce et plus rapide

non. En général SmartLinking fonctionne comme ceci:

• Si vous utilisez une unité quelque part, au moins le code Inialization et finalisation est lié à.
• En principe, seules les fonctions / méthodes que vous utilisez réellement, directement ou indirectement à partir du programme principal (.DPR) sont liés.
• Certains bits accessibles via RTTI seront également liés. La règle de gézantique est que RTTI pour Enums est toujours liée dans (si vous utilisez l'ENUM), et que (dès que vous construire une classe), tout publié ou accessible via des propriétés publiées est lié à.
• Gardez à l'esprit que l'initialisation d'unités inutilisées pourrait tirer dans dlls ou même des cadres entières de DLL (comme .NET) qui pourrait constituer une complication inutile de réapprovisionnement.
• (comme Rob dit dans les commentaires) Ressources sont un autre facteur toujours lié dans, car en raison de leur utilisation d'exécution, le compilateur ne peut pas déterminer si elles sont utilisées ou non.
• dans les DLL ou les projets d'emballage, tous les symboles publiés seront liés, car un programme externe pourrait les appeler.

  Conclusion: la dernière taille .exe est déterminée

  • principalement par tout ce qui est accessible par des racines ci-dessus (principalProgramme, initialisation, finalisation, RTTI des classes qui peuvent être construites),
  • Certains bits qui sont toujours liés si l'unité est utilisée (ressources, certaines formes de RTTI comme Enums),
  • Aides de langue dans la RTL, comme des routines d'assistant de distribution, la plupart d'entre elles sont dans le système, certaines pourraient être en variantes.
  • Quelques petites Administration du programme interne (E.G. Tables avec des unités qui déterminent l'ordre d'initialisation / finalisation), Tables nécessaires à la manipulation de ressources, à la liaison DLL, etc.
  • info de débogage (si TD32 sur)
  • Paramètres du compilateur Comme l'optimisation et les vérifications d'exécution sont également légèrement influencer la taille binaire.
  • La compression binaire utilise comme UPX. Je Ne recommande pas Celles-ci, car dans mon expérience, ils causent constamment des problèmes.

    Free Pascal fonctionne grossièrement de la même manière, les valeurs par défaut sont simplement différentes; Débogage est actuellement presque toujours "en binaire" (comme TD32) et dans les instantanés, SmartLinking est désactivé par défaut. (Dans les versions officielles, c'est sur).

    En outre, il ne faut pas perdre de vue la magnitude. Strutils dans son intégralité est comme 15kb max.

    (mise à jour 2011-11-01)

    Vous avez obtenu une remarque de SB sur cette réponse, j'ai aimé partager:

    En gros, il a mis en doute sur la remarque que les énums sont toujours liées. Peut-être que l'enregistrement d'une classe qui a une propriété publiée du type ENum les dragose. Le raisonnement a du sens, mais je ne l'ai pas encore testé. Donc, RTTI de Enum peut être uniquement lié si TypeInfo (tenualtype) est interrogé quelque part ou s'il est utilisé dans une section publiée de la classe utilisée. (directement ou TypeInfo (Theclass) est interrogé)