2009-10-14 10 views
1

je une condition de débogage pour gérer la mémoire où jeutilisation de méthodes externes entre projets dll?

extern void* operator new(unsigned int size, const char* file, int line); 
    extern void operator delete(void* address, const char* file, int line); 
    extern void Delete(void* address); 
    #define FUN_NEW new(__FILE__, __LINE__) 
    #define FUN_DELETE delete 

Cela existe dans memory.h et est mis en œuvre dans Memory.cpp. Memory.h est défini comme:

#ifdef MEMORY_EXPORT 
#define DECL_MEMORY __declspec(dllexport) 
#else 
#define DECL_MEMORY __declspec(dllimport) 
#endif 
class DECL_MEMORY Memory : public Singleton<Memory> 
{ 

maintenant, je SoundStuff.h et SoundStuff.cpp, qui sont dans un projet séparé, converti également à une dll de manière similaire ci-dessus. Le projet auquel appartient SoundStuff a une dépendance de projet par rapport au projet auquel appartient Memory. Dans l'implémentation de SoundStuff.cpp, FUN_DELETE, à partir de Memory.h, est appelée. Il est appelé via une fonction dans un projet distinct, mais il est appelé indépendamment. Cela conduit à des erreurs de linker.

erreur LNK2019: symbole externe non résolu "opérateur void __cdecl supprimer (void *, char const *, int)" (?? 3 @ YAXPAXPBDH @ Z) référencé dans fonction __unwindfunclet $ Init @ SoundStuff @@ AAEXXZ $ 1 SoundStuff.obj

Pourquoi est-ce et comment puis-je le réparer?

+0

Veuillez montrer comment vous liez CoreFunctions à DoSomeStuff. –

+0

Ajouté à la description Il y a une dépendance de projet là et la fonction Init d'une classe dans DoSomeStuff appelle FUN_DELETE, qui est définie dans CoreFunctions – Mark

+0

Merci. Un autre bit vous dites: "Il est appelé à travers une fonction dans un projet séparé" - pouvez-vous préciser ce que cela signifie dans ce cas? Voulez-vous dire que 'SoundStuff.cpp' appelle une fonction dans un autre projet, qui à son tour appelle' FUN_NEW'? Si c'est le cas, est-ce que le code de cet autre projet fait aussi # #include "Memory.h" '? –

Répondre

1

Vous devez indiquer explicitement au compilateur quelles fonctions vous souhaitez exporter. Il y a une petite chanson et de danse pour ce faire, voici comment je le fais:

#ifdef USING_DLL 
#ifdef CORE_EXPORTS 
#define CORE_EXPORT __declspec(dllexport) 
#else 
#define CORE_EXPORT __declspec(dllimport) 
#endif 
#else 
#define CORE_EXPORT 
#endif 

Chaque fonction (ou classe) Je voudrais exporter taggés avec CORE_EXPORT obtient. Pour construire pour les DLL, définissez USING_DLL et dans votre projet CoreFunctions (mais pas votre projet DoSomeStuff) définissez CORE_EXPORTS. Cela garantira que vos fonctions/classes sont déclarées __declspec(dllexport) lorsque la DLL CoreFunctions est en cours de construction (donc elles sont exportées), et __declspec(dllimport) lorsque DoSomeStuff est en construction (elles sont donc importées).

+0

Ceci est vrai, désolé de ne pas l'avoir spécifié. J'ai déjà fait ça. J'ai étiqueté absolument chaque classe avec cette macro – Mark

+0

Alors, à quoi ressemblent vos prototypes de fonction? – Sol

+0

Ou ces fonctions font-elles partie d'une déclaration de classe? – Sol