Quelle est la convention de dénomination appropriée pour les DLL MSVC, les bibliothèques statiques et les bibliothèques d'importation

Comme les autres l'ont dit, il n'y a pas de standard pour désigner des fenêtres.

Pour notre base de produits complète qui couvre 100 d'EXES, DLL et Static Libs que nous avons utilisé le Suivre avec succès depuis de nombreuses années et il a sauvé beaucoup de confusion. C'est fondamentalement un mélange de plusieurs méthodes que j'ai vues utilisées au fil des ans.

en un mot de notes Tous nos fichiers d'un préfixe et d'un suffixe (n'incluant pas l'extension elle-même). Ils commencent tous avec "OM" (basé sur notre nom de société), puis ont une combinaison de 1 ou 2 caractères qui identifie approximativement la zone de code.

Le suffixe explique quel type de fichier intégré ils sont et inclut jusqu'à trois lettres utilisées en combinaison en fonction de la construction qui inclut Unicode, statique, débogage (DLL Builds est la valeur par défaut et n'a aucun identifiant de suffixe explicite). Lorsque nous avons démarré ce système Unicode n'était pas aussi répandu et nous avons dû prendre en charge les bâtiments Unicode et non Unicode (PRE Windows 2000 OS), tout est maintenant construit de manière exclusive unicode, mais nous utilisons toujours la même nomenclature.

Donc un "ensemble" typique "de fichiers peut ressembler à xxx

Tous les fichiers sont intégrés dans un dossier couronné de bin, qui élimine beaucoup de problèmes de DLL-enfer pour Les développeurs et facilitent également les réglages de compilateur / lieur - ils indiquent tous le même emplacement à l'aide de chemins relatifs et qu'il n'y a jamais de besoin de copie manuelle (ou automatique) des bibliothèques ayant des besoins de projet. Avoir ces suffixes élimine également toute confusion sur quel type de fichier que vous pouvez avoir et vous garantit que vous ne pouvez pas avoir de scénario mixte où vous posez la DLL de débogage sur une trousse de sortie ou inversement. Tous les exès utilisent également un suffixe similaire (Unicode / Débug) et construire dans le même dossier Bin.

Il y a également un seul dossier "Inclure", chaque bibliothèque dispose d'un fichier d'en-tête dans le dossier Inclure qui correspond à la Nom de la bibliothèque / DLL (par exemple omfthread.h) qui se dépose #inclut tous les autres éléments exposés par cette bibliothèque. Cela conserve sa plus simple si vous voulez des fonctionnalités qui sont en foo.dll vous venez de simplement #include "foo.h"; Nos bibliothèques sont hautement segmentées par des zones de fonctionnalité - nous n'avons pas de DLL "Swiss-Army Count", de sorte que les bibliothèques entières fonctionnelles ont du sens. (Chacun de ces en-têtes comprend également d'autres en-têtes préalables, qu'ils soient nos bibliothèques internes ou parmi les SDK de fournisseur)

chacun de ces fichiers utilise en interne utilise des macros qui utilisent # pramga's pour ajouter le nom de la bibliothèque approprié à la ligne de liaison. Les projets individuels n'ont donc pas besoin de se préoccuper de cela. La plupart de nos bibliothèques peuvent être construites statiquement ou comme une DLL et #define om_link_static (si définie) (si définie) est utilisée pour déterminer quel projet individuel veut (nous utilisons habituellement les DLL mais dans certains cas, les bibliothèques statiques intégrées dans le fichier .exe. plus de sens pour le déploiement ou d'autres raisons) xxx

Ces macros (omlibnamnestatic & omlibname) utilisent _debug Déterminer quel type de construction est et génère le nom de la bibliothèque approprié à ajouter à la liaison Ligne.

Nous utilisons une définition courante dans les versions statiques et DLL d'une bibliothèque afin de contrôler l'exportation correcte de la classe / des fonctions dans les bâtiments DLL. Chaque classe ou fonction exportée de la bibliothèque est décorée avec cette macro (dont le nom correspond au nom de base de la bibliothèque, bien que cela soit largement sans importance) xxx

dans la DLL Version des paramètres du projet que nous définissons omfthread_declare = __ DeclSpec (Dllexport), dans la version statique de la bibliothèque de la bibliothèque que nous définissons omfthread_declare comme vide .

dans le fichier d'en-tête des bibliothèques que nous définissons Basé sur la manière dont le client tente de créer un lien avec celui-ci xxx

un projet typique qui souhaite utiliser l'une de nos bibliothèques internes, il suffirait d'ajouter les incluations appropriées à leur stdadafx.h ( En règle générale) et cela fonctionne simplement, s'ils doivent être liés à la version statique, il suffit d'ajouter om_link_static à leurs paramètres de compilateur (ou de le définir dans STDAFX.H) et il fonctionne à nouveau.