Strange error with overloaded function name
-
I had this function in a class i defined :
void AddJob(IRunnable &NewJob);
Now there is a Windows API that is also called
AddJob, but with completely different parameters and return type. The class was defined inside a static library. When i wanted to call that function in an application that linked my library :TestInstance.AddJob(IRunnableImplInstance);
i got a linker error "Unresolved external". I renamed my functio now, and all works well. But i wonder why the error occured in the first place. The function had completely different parameters, return types and class context (the API is in the global namespace). I use VC++ 6. Does anyone have an explanation for that ?
-
I had this function in a class i defined :
void AddJob(IRunnable &NewJob);
Now there is a Windows API that is also called
AddJob, but with completely different parameters and return type. The class was defined inside a static library. When i wanted to call that function in an application that linked my library :TestInstance.AddJob(IRunnableImplInstance);
i got a linker error "Unresolved external". I renamed my functio now, and all works well. But i wonder why the error occured in the first place. The function had completely different parameters, return types and class context (the API is in the global namespace). I use VC++ 6. Does anyone have an explanation for that ?
I believe that C functions, even when compiled by a C++ compiler only differ by name and not by return type, name and parameter list for C++ member functions. Would this be the culprit?
Chris Meech I am Canadian. [heard in a local bar] Nobody likes jerks. [espeir] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
-
I believe that C functions, even when compiled by a C++ compiler only differ by name and not by return type, name and parameter list for C++ member functions. Would this be the culprit?
Chris Meech I am Canadian. [heard in a local bar] Nobody likes jerks. [espeir] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
I don't know for shure. But i think unsell you declare a function
__stdcallexplicitly, it will always be translated into that long C++ symbol lingo. However, why would that result in an unresolved external linker error ? If anything it's a redefinition of a symbol, but not no definition of that symbol. -
I had this function in a class i defined :
void AddJob(IRunnable &NewJob);
Now there is a Windows API that is also called
AddJob, but with completely different parameters and return type. The class was defined inside a static library. When i wanted to call that function in an application that linked my library :TestInstance.AddJob(IRunnableImplInstance);
i got a linker error "Unresolved external". I renamed my functio now, and all works well. But i wonder why the error occured in the first place. The function had completely different parameters, return types and class context (the API is in the global namespace). I use VC++ 6. Does anyone have an explanation for that ?
This one is going to make you laugh :laugh: and cry :sigh: ... In the Microsoft headers, there are TWO definitions for almost every function - the ANSI version and the UNICODE version. The AddJob in the Microsoft headers is redefined as either AddJobA or AddJobW. The precompiler will see any similar text and change the name. Now, in your static library, you must NOT have included anything close to the printer header, so the AddJob stayed as 'AddJob', but in your project, when you went to use it, and maybe you directly or indirectly included the files which redefined AddJob, so it did not find AddJobA or AddJobW in your library at link time - your project's main OBJ module was looking for the wrong name. I had been tripped up by this one time a while back as well. You have to be careful naming anything requiring linkage the same as any one of the bazillion WIN32 functions out there! This would also explain why once you changed the name your 'problem' went away.
Any sufficiently gross incompetence is nearly indistinguishable from malice.
-
This one is going to make you laugh :laugh: and cry :sigh: ... In the Microsoft headers, there are TWO definitions for almost every function - the ANSI version and the UNICODE version. The AddJob in the Microsoft headers is redefined as either AddJobA or AddJobW. The precompiler will see any similar text and change the name. Now, in your static library, you must NOT have included anything close to the printer header, so the AddJob stayed as 'AddJob', but in your project, when you went to use it, and maybe you directly or indirectly included the files which redefined AddJob, so it did not find AddJobA or AddJobW in your library at link time - your project's main OBJ module was looking for the wrong name. I had been tripped up by this one time a while back as well. You have to be careful naming anything requiring linkage the same as any one of the bazillion WIN32 functions out there! This would also explain why once you changed the name your 'problem' went away.
Any sufficiently gross incompetence is nearly indistinguishable from malice.
Well, it made me laugh more than cry. I knew that most of the functions are mapped to the A and W version via macros, but i didn't make the connection. Well, you just gotta take it with humor ...
-
This one is going to make you laugh :laugh: and cry :sigh: ... In the Microsoft headers, there are TWO definitions for almost every function - the ANSI version and the UNICODE version. The AddJob in the Microsoft headers is redefined as either AddJobA or AddJobW. The precompiler will see any similar text and change the name. Now, in your static library, you must NOT have included anything close to the printer header, so the AddJob stayed as 'AddJob', but in your project, when you went to use it, and maybe you directly or indirectly included the files which redefined AddJob, so it did not find AddJobA or AddJobW in your library at link time - your project's main OBJ module was looking for the wrong name. I had been tripped up by this one time a while back as well. You have to be careful naming anything requiring linkage the same as any one of the bazillion WIN32 functions out there! This would also explain why once you changed the name your 'problem' went away.
Any sufficiently gross incompetence is nearly indistinguishable from malice.
-
I don't know for shure. But i think unsell you declare a function
__stdcallexplicitly, it will always be translated into that long C++ symbol lingo. However, why would that result in an unresolved external linker error ? If anything it's a redefinition of a symbol, but not no definition of that symbol.You're correct. I've got it backwards. My explanation would result from a redefinition error. Not what you are after. Sorry about that. :-O
Chris Meech I am Canadian. [heard in a local bar] Nobody likes jerks. [espeir] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]