Why do static varaibles cause issues on dllimport
Author
I am missing something, If I have am trying to do an import export on a class that has static variables I get a ton of link errors saying:
AnomalyCore.dll error LNK2001: unresolved external symbol "__declspec(dllimport) private: static int AnomalyHeap::m_nNextAllocNum" (__imp_?m_nNextAllocNum@AnomalyHeap@@0HA)
I sware I have seen code that uses dll import/export on classes with static members before, any advice?
// Class.hclass MyClass{public:MyClass(void);static int MyVar;}// Class.cpp// Do you have something like this?int MyClass::MyVar = 0;MyClass::MyClass(void){}Do you have the static variable declared in your cpp file for your Dll so that the linker has something to link to? The linker won't generate errors for missing static variable references in classes until you try to link the library to an actual program.
Author
It basicly looks like this:
/.h file--------------------------------------------
#ifdef HEAP_EXPORTS
#define HEAP_API __declspec(dllexport)
#else
#define HEAP_API __declspec(dllimport)
#endif
class HEAP_API AnomalyHeap
{
public:
//stuff
private:
static int m_nNextAllocNum;
};
/.cpp file----------------------------------------
#define HEAP_EXPORTS
int AnomalyHeap::m_nNextAllocNum = 0;
So now with that in the cpp file I get the compile error:
error C2491: 'AnomalyHeap::m_nNextAllocNum' : definition of dllimport static data member not allowed
/.h file--------------------------------------------
#ifdef HEAP_EXPORTS
#define HEAP_API __declspec(dllexport)
#else
#define HEAP_API __declspec(dllimport)
#endif
class HEAP_API AnomalyHeap
{
public:
//stuff
private:
static int m_nNextAllocNum;
};
/.cpp file----------------------------------------
#define HEAP_EXPORTS
int AnomalyHeap::m_nNextAllocNum = 0;
So now with that in the cpp file I get the compile error:
error C2491: 'AnomalyHeap::m_nNextAllocNum' : definition of dllimport static data member not allowed
MSDN: C2491
Are you including the .h file anywhere before the .cpp file, or rather, before the #define HEAP_EXPORTS directive? In that case, it'll use dllimport in the class, then try to define m_nNextAllocNum which is not allowed.
[Edited by - Luctus on February 15, 2005 4:46:37 AM]
Are you including the .h file anywhere before the .cpp file, or rather, before the #define HEAP_EXPORTS directive? In that case, it'll use dllimport in the class, then try to define m_nNextAllocNum which is not allowed.
[Edited by - Luctus on February 15, 2005 4:46:37 AM]
Author
It is possible I included it somewhere else. I was able to solve the problems by changing class HEAP_API AnomalyHeap to just class AnomalyHeap. This would mean that it is not getting the export/import for the DLL, however when I link the DLL to my test program everything still works. I am not sure why it still works with out that....
I'm having this exact same problem.
I am receiving a ton of linker errors from static member variables, all of which are private or protected, when I try to import my DLL. They all come up as unresolved external symbols.
I tried putting __declspec(dllexport) both at class declaration and at the variables' initialization in the appropriate .cpp, which compiles alright, but the linker errors don't budge.
- carb
I am receiving a ton of linker errors from static member variables, all of which are private or protected, when I try to import my DLL. They all come up as unresolved external symbols.
I tried putting __declspec(dllexport) both at class declaration and at the variables' initialization in the appropriate .cpp, which compiles alright, but the linker errors don't budge.
- carb
Author
Carb, aparently you just can't do it. I searched google for hours trying to find something with no luck. Try using ONLY __declspec(dllexport) for the class. I have no idea why it still works with out ever doing the dllimport on the class but this solved the link errors and when I used my dll with the exe it behaved exactly as I wanted/expected it to in the fist place. Good luck!
I tried using it only for the class - that's where the problem started.
I think it can be done - I think this is just an uncommon/rare case we've stumbled upon. Otherwise there WOULD be more literature on why it can't be done. I've found examples on the net that show a class with static members being exported properly. Why mine/ours doesn't work is beyond me ... that's why I'm here ;)
- carb
I think it can be done - I think this is just an uncommon/rare case we've stumbled upon. Otherwise there WOULD be more literature on why it can't be done. I've found examples on the net that show a class with static members being exported properly. Why mine/ours doesn't work is beyond me ... that's why I'm here ;)
- carb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
