2010-12-28 4 views
0

Actuellement mon studio visuel génère essentiellement Engine.dll et Game.exe.lib reliant d'autres .libs

liens Engine.dll à d'autres bibliothèques de base comme: d3dx9d.lib ComCtl32.lib Winmm.lib WSock32.lib etc.

Je voulais aussi essayer de créer un fichier Engine.lib, mais je reçois maintenant de très jolis avertissements: Symbol x a déjà été défini. Ces bibliothèques définissent les mêmes symboles.

Donc, j'ai lu quelque part que je dois forcer mon utilisateur (Game.exe) à lier les libs à la place. Mais c'est vraiment très gênant je pense, surtout si j'ai beaucoup de jeux et que je décide d'ajouter une autre librairie à mon moteur. C'est juste de la maintenance pour quelque chose d'aussi simple.

Dois-je m'en tenir au .dll, ou y a-t-il un moyen de réparer cette beauté?

Merci beaucoup,

Antoon

Répondre

1

Avez-vous créé un espace de noms différent pour éviter de nommer des affrontements?

EDIT - semble qu'il y a une certaine confusion quant à ce que vous demandez, parce que vous posez quelques questions. Pour moi, il semble que vous vouliez essayer de mettre en œuvre votre propre classe de moteur. Cependant, vous avez des problèmes de nommage. Je traite cela comme plus d'une question architecturale maintenant. Si vous écrivez votre jeu sur une interface, le problème disparaît. Par exemple, si votre moteur utilise des algorithmes différents, si vous avez écrit une EngineInterface implémentée par le moteur et YourEngine en cours, vous pouvez facilement utiliser Strategy pour basculer entre les différentes implémentations à la volée. C'est bien parce que vous pourrez voir les différences dans le jeu si vous connectez les préférences dans l'application.

+0

Vous voulez dire que je devrais complètement emballer les libs et les rendre inutiles pour les utilisateurs? – Xilliah

+0

Je dis simplement que si votre application fait appel à une interface plutôt que quelque chose de concret, l'implémentation sous-jacente n'est pas pertinente. Vous pouvez envelopper d3dx9d, winmm, etc dans la DLL moteur actuelle, mais vous pouvez utiliser opengl dans MyEngine DLL.L'application (ce qui est essentiellement "l'utilisateur") ne devrait pas s'en préoccuper. – Dave

0

Si les symboles ne sont pas censés être identiques, utilisez des noms différents ou contrôlez la façon dont ils sont exposés. Une autre option est l'utilisation des espaces de noms pour éviter les conflits de noms.

Si les symboles sont censés être la même chose, vous devez les définir une seule fois dans l'une des bibliothèques.

+0

on peut utiliser des espaces de noms autour d'inclus? – Xilliah

+0

L'éditeur de liens ne pourra pas trouver les fonctions de cette manière, uniquement si vous utilisez l'espace de noms sur les inclus et sur la définition de la fonction. – bcsanches

2

Vous devez vous décider si vous voulez la DLL ou la bibliothèque de liens statiques. L'avantage d'une DLL est que les temps de construction peuvent être plus rapides si vous faites des changements locaux. L'avantage d'un .lib est que vous vous retrouverez avec un seul fichier déployable.

L'obtention de ce lien (soit l'importation statique .lib soit l'importation .lib de la DLL) est sinon automatique. Vous voulez vous assurer que la bibliothèque est construite en premier, ne peut pas lier le .exe sans elle. Cliquez avec le bouton droit sur le projet exe dans la fenêtre Explorateur de solutions, Dépendances de projet, cochez le projet de bibliothèque. Cela ajoute automatiquement le fichier .lib aux dépendances supplémentaires du projet exe. L'utilisation de #pragma comment (lib, "engine.lib") dans le fichier d'en-tête du moteur est une autre manière. Répétez l'opération pour les autres dépendances telles que les bibliothèques d'importation du système d'exploitation. Obtenir le bon chemin d'accès à la bibliothèque est un élément // todo.