LNK2001 on static member variables 
Author Message
 LNK2001 on static member variables

I see

being that those function's dont have a this pointer, they probably cant
access the data that way try:

class __declspec(dllexport) Blah
{
     public:
       static HFONT s_GetDefaultFont ( ) {return Blah::s_hfntDefault;}
       static COLORREF s_GetDefaultColor ( ) {return Blah::s_clrDefault;}


Quote:
> Do you have a CPP file that creates them?  They wont exist otherwise.

> HFONT Blah::s_hfntDefault = value;



> > Hi.

> > I'm converting a bunch (450K lines) of C++ code from 16 to 32 bit.
> > I'm also switching from BC++ 4.52 to VC++ 6.  I've gotten past lots of
> > compatibility issues, but one problem that continues to plague me is
> > that I'm getting LNK2001 errors all over the place where I call
> > functions that reference static class data members.

> > For example:

> >  class __declspec(dllexport) Blah
> >  {
> >     public:
> >        static HFONT s_GetDefaultFont ( ) {return s_hfntDefault;}
> >        static COLORREF s_GetDefaultColor ( ) {return s_clrDefault;}
> >     private:
> >        static HFONT s_hfntDefault;
> >        static COLORREF s_clrDefault;
> >  };

> > When I link code that calls either of the static member functions in
> > the above class, I get the LNK2001 error for the private static member
> > variables that are referenced.  Can anybody shed some light on this?

> > Thanks,
> > Andy



Sat, 03 Aug 2002 03:00:00 GMT  
 LNK2001 on static member variables


Quote:
> being that those function's dont have a this pointer, they probably cant
> access the data that way try:

> class __declspec(dllexport) Blah
> {
>      public:
>        static HFONT s_GetDefaultFont ( ) {return Blah::s_hfntDefault;}
>        static COLORREF s_GetDefaultColor ( ) {return Blah::s_clrDefault;}

You should not need to do that.  Whatever the probelm is,
that ought not to be it.  Static functions should be able to
get at static data with no problem.

To the OP.  Can you post a minimal compilable code that
actually displays the symptom?  I'm thinking there is something
whacky about include files and definitions of HFONT and
COLORREF and so on, and that it may be causing the
compiler to be confused about what the function names
and data member types really are.  So the problem may be
that the compiler is giving you a misleading diagnositc.

--
Dan Evens
Standard disclaimers etc. No spam please.
Just because nobody complains does not
mean that all parachutes are perfect.



Sun, 04 Aug 2002 03:00:00 GMT  
 LNK2001 on static member variables
I believe I've found my problem.  

In the "real" code I was using some macros for the import/export
stuff.  I have the following macros (simplified here to remove
compiler vendor differences):

 #ifdef __DLL_ _
   #define DLLCLASS __declspec(dllexport)  
   #define DLLAPI __declspec(dllexport) WINAPI
   #define DLLCDECL __declspec(dllexport) __cdecl  
 #else
   #define DLLCLASS __declspec(dllexport)
   #define DLLAPI __declspec(dllimport) WINAPI
   #define DLLCDECL __declspec(dllimport) __cdecl
 #endif

I ensure that __DLL__ is defined for all DLL builds and that it is
*not* defined for EXE builds.  So the class I represented as 'Blah'
was using DLLCLASS instead of the literal '__declspec'.  The flaw was
in the definition of the DLLCLASS for non-DLL builds.  The line should
read:

   #define DLLCLASS __declspec(dllimport)

I actually looked at this stuff right off the bat, but probably just
read right past the bug.  The odd thing is that I've gotten as far as
I have w/out catching this.  I've already converted two of our
low-level DLLs and two unit-testing apps.  Now that I think about it,
this explains why my two test apps were generating .LIB files when I
built them.  Duh.

Anyway, I made the correction, went back in and changed about 100
places in the two test apps where I was incorrectly defining classes
and functions with DLLCLASS or DLLAPI and everything built and ran
correctly.

Andy

Quote:



>> being that those function's dont have a this pointer, they probably cant
>> access the data that way try:

>> class __declspec(dllexport) Blah
>> {
>>      public:
>>        static HFONT s_GetDefaultFont ( ) {return Blah::s_hfntDefault;}
>>        static COLORREF s_GetDefaultColor ( ) {return Blah::s_clrDefault;}

>You should not need to do that.  Whatever the probelm is,
>that ought not to be it.  Static functions should be able to
>get at static data with no problem.

>To the OP.  Can you post a minimal compilable code that
>actually displays the symptom?  I'm thinking there is something
>whacky about include files and definitions of HFONT and
>COLORREF and so on, and that it may be causing the
>compiler to be confused about what the function names
>and data member types really are.  So the problem may be
>that the compiler is giving you a misleading diagnositc.



Sun, 04 Aug 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. static function access member variable and member function

2. An Easy Question Regarding Static Member Linkage: LNK2001

3. static member - LNK2001

4. Static class members in DLLs (LNK2001 error)

5. static int member causing LNK2001 error

6. Static Variables and error LNK2001

7. Advices needed: static variables - error lnk2001

8. static member variables

9. static member variable inside class

10. LNK1169 & static const class member variables

11. C2086 error: static local variables in member functions

12. Export static member variables in DLL

 

 
Powered by phpBB® Forum Software