Thread: linker error with static member...

Code:

class Binary
{
    public:
        template<typename T>static void reverseBytes(T& input)
        {
            reverseBytes<sizeof(T)>((unsigned char*)&input);
        }
    private:
    
        static unsigned char holder;//LNK2020, LNK2001
        template<unsigned int N>inline static void reverseBytes(unsigned char* input)
        {
            holder = *input;
            *input=*(input+N-1);
            *(input+N-1)=holder;
            reverseBytes<N-2>(++input);
        }
        template<>inline static void reverseBytes<2>(unsigned char* input)
        {
            holder = *input;
            *input=*(input+1);
            *(input+1)=holder;
        }
        template<>inline static void reverseBytes<1>(unsigned char* input){}
};

Any ideas why does the line above generates unresolved token / unresolved external symbol errors in VS2k5?

Did you ever bother to do

Code:

unsigned char Binary::holder;

anywhere? You need to do it exactly once.

odd. thanks.

Well, yes, one is an odd number, but I doubt that's where you were headed with that. You put an extern reference in your class (that's what static is -- it's not a member object since each member doesn't get its own), so you must have an actual object somewhere for that reference to refer to.

yes, it makes sense, it's just odd the compiler doesn't do it for you automagically if it's a primitive value or other value type with a default ctor.

unfortunately, i've been out of the C++ world for a while; this is one of those bits of trivia that seems to have leaked out of my memory.

For when it comes up later, that code is not standard compliant.

You need to move the specialization of template member functions of simple classes into the scope containing those classes. (For template classes, the enclosing template class itself must be specialized as well.)

Further more, fully specialized function templates, even though they may look like function templates, are not templates. They are functions. They are treated, by the compiler and linker, as functions and not templates. In other words, the special behavior characterized by C++ compilers and linkers that allow multiple definitions for template functions will not be allowed for fully specialized template functions. Basically, this example would only work, if the specializations were moved outside the class definition, because you have marked them as `inline'; if you change that bit, you'll get multiple definition errors. In order to fix that, you'll have to treat them as you would any other function overload; you will declare them in a header and put the definition in a translation unit (a C++ source file).

Finally, you have a bug; your code will find infinitely recursion and so compilers will refuse to compile.

Soma

Code:

class Binary
{
    public:
        template<typename T>static void reverseBytes(T& input)
        {
            reverseBytes<sizeof(T)>((unsigned char*)&input);
        }
    private:
    
        static unsigned char holder;//LNK2020, LNK2001
        template<unsigned int N>inline static void reverseBytes(unsigned char* input)
        {
            holder = *input;
            *input=*(input+N-1);
            *(input+N-1)=holder;
            reverseBytes<N-2>(++input);
        }
};
        template<>inline void Binary::reverseBytes<2>(unsigned char* input)
        {
            holder = *input;
            *input=*(input+1);
            *(input+1)=holder;
        }
        template<>inline void Binary::reverseBytes<1>(unsigned char* input){}

to be honest, i didn't catch all of that.

it ran just fine. it gave the same result as the looping implementation i am replacing...

and i really don't care about std compliance. this is part of a C++/CLI project, so standardization is not a consideration.

O_o

Okay.

That's fine that you didn't catch it. Happily, the post is still there.

Keep reading it until you do "catch it". Or at least ask a question about what you didn't get.

it ran just fine.

And you are using either the "MSVC" compiler or a couple of versions of the Intel compiler.

Soma

yes, as in the OP, i'm using VS2k5. portability isn't a concern. thanks for the heads-up though.

Yes, I knew what you were using; I was saying that you'd be limited to only those as it stands. If that isn't a problem, so be it.

Soma