View Full Version : Class, linker error
recluse
05-28-2002, 04:04 PM
I decided to use my lunch break, between class and my internship, to (re)teach myself c++ by doing it more than just sitting in a classroom and listening.
Unfortunately I can get this little program to compile, I'm getting some sort of linker error:
" unresolved external symbol "public: double __thiscall foolib::cube(int)" (?cube@foolib@@QAENH@Z)
Debug/prog01.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe."
Though I doubt that will help. Here's the code.
************prog01.cpp **********************
#include <iostream.h>
#include "foolib.h"
int main(){
int cubeMe = 0;
foolib x;
cout << "Enter a number to be cubed: ";
cin >> cubeMe;
cout << "\n" << cubeMe << " is " << x.cube(cubeMe);
cout << " when cubed." << endl;
return 0;
}
*********************************************
***********foolib.h***************************
class foolib
{
public:
template <class T>
double cube(T value);
};
*********************************************
************foolib.cpp**************************
#include "foolib.h"
template <class T>
double foolib::cube(T value)
{
return (value * value * value);
}
*********************************************
For those of you that 'know' me and are seeing the ".exe" part of the error and are thinking "Huh? I thought he was a *nixphile" I'm doing this on campus and not at home. Just to clarify:p
Strike
05-28-2002, 04:24 PM
You have to compile foolib into an object file first (in Unixland this would be a .o file), and then when you compile prog01.cpp, you would compile that object file with it. So, in Linux this process would be:
gcc -c -o foolib.o foolib.cpp
gcc -o prog01 prog01.cpp foolib.o
recluse
05-28-2002, 04:32 PM
Anyone know how to do this with MS VC++ ?
Strike, thanks for the info. I guess I should read up on make files =)
Strike
05-28-2002, 04:47 PM
You should be able to specify it, but I forget how. It has been ages since I've used MSVS. It's in the build options somewhere. Google for "building and linking libraries with MS Visual Studio" maybe ..
sans-hubris
05-28-2002, 04:59 PM
Oh, oh, oh, the other problem is that you're using templates. Ideally, you should just need to use the export keyword, but most compilers (g++ and MSVC included) do not have this implemented (it is extremely difficult to implement.)
For now, the only solution is to #include the .cpp at the end of the .h file.
Well, actually, that's not the only solution, but it's the easiest.
file13
05-28-2002, 05:01 PM
to add files on VC++ click on new and then pick, source file or header file, then the file itself. you may also need to right click on the project thingie on the left hand side and add files to project.
FYI: Standard C++ does NOT use .h files for standard libs:
http://www.snurse-l.org/acllc-c++/faq.html#q3.5
but the whole thing is really good:
http://www.snurse-l.org/acllc-c++/faq.html
file13
05-28-2002, 05:12 PM
Originally posted by sans-hubris
Oh, oh, oh, the other problem is that you're using templates. Ideally, you should just need to use the export keyword, but most compilers (g++ and MSVC included) do not have this implemented (it is extremely difficult to implement.)
For now, the only solution is to #include the .cpp at the end of the .h file.
Well, actually, that's not the only solution, but it's the easiest.
yeah you're right--just tried it. VC++ sucks! but foolib.h would look like this then if you did it inline:
class foolib {
public:
template <class T>
double cube(T value) { return (value * value * value); }
};
jeez, gcc 2.96 (i know) didn't even link it correctly. C++. that's why i like Ada! where compilers actually support the standard! ;)
Strike
05-28-2002, 05:35 PM
Heh, you may "know", but talking about standards compliance when using gcc 2.96 (literally, a broken compiler) for ammunition ...
file13
05-28-2002, 06:08 PM
true true. that's why i said "i know." ;)
it's a "production box" so i can't screw with gcc 3.1 here. have you tried "export" on 3.1?
hey i guess i could try the mingw 3.1 on the windows box...hummm.....
sans-hubris
05-28-2002, 08:16 PM
Don't blame the compiler (this includes VC++!) IMO, excluding gcc, VC++ is the best compiler for Windows, seriously. I've worked with Borland, LCC, and a few others on Windows, and if I can't use gcc, I'd much rather use VC++. Who would guess that one of the best compilers for the OS would be by the authors of the OS?!
As I said earlier, don't blame the compiler for noncompliance. C++ is extraordinarily difficult to implement. I just took a programming languages class, and we had to implement a relatively, but complete, language, which was difficult by itself. Its type-checking is relatively simple compared to some languages, but some of the syntax is a little weird, and is rather context sensitive. That'd be a nightmare to implement.
Even if you had written the parsor correctly, interpreting the resulting tree still requires a lot of thought. I would imagine, and this is a guess, that templates would be implemented in a manner similar to static, nested functions in other languages. That is in itself very difficult to do.
I'll stop ranting now and leave you to ponder the difficult job of language implementers. You can say an implementation sucks, but don't forget how hard it was to get to that point.
recluse
05-28-2002, 09:20 PM
Another thing I just thought of is that I should be putting in some
ifndef define foo
endef
type statement in there. Unfortunately I forgot the syntax, I'll look it up and try these suggestions tomorrow. Thanks guys!
file13
05-28-2002, 11:23 PM
Originally posted by sans-hubris
Don't blame the compiler (this includes VC++!) IMO, excluding gcc, VC++ is the best compiler for Windows, seriously. I've worked with Borland, LCC, and a few others on Windows, and if I can't use gcc, I'd much rather use VC++. Who would guess that one of the best compilers for the OS would be by the authors of the OS?!
As I said earlier, don't blame the compiler for noncompliance. C++ is extraordinarily difficult to implement. I just took a programming languages class, and we had to implement a relatively, but complete, language, which was difficult by itself. Its type-checking is relatively simple compared to some languages, but some of the syntax is a little weird, and is rather context sensitive. That'd be a nightmare to implement.
i couldn't agree more. i recommend folks who want to do C++ on windows to get VC++. it still dosen't make it a good compiler as far as language compliance or even optimization--unless you pay $$$ for the enterprise.... i find it annoying to have to include return 0 when the standard states it's redundant. i find it annoying that after they both to copy Ada's generics that they can't even implement them correctly. after taking to time to learn C++ i find it annoying that the compiler vendor's can't take the time to support the standard that i learned. now i'm not at all knocking the GNU folks because LONG LIVE FREE SOFTWARE! they do it for free. but M$ (and every other commerical C++ compiler that dosen't suppor the standard...all but one?) has no excuse to not implement the language standard except that they don't care to. look at Ada 95. Ada had all of the nifty features C++ has now before C++ and guess what, the compilers support it. all of it. in fact the Ada community demands it. the C++ community dosen't honetly seem to care and that very well could be the reason the compiler vendors don't either. hell, i haven't even seen a C99 compiler!
bottom line, when you learn a "Standardized" ANSI/ISO language you expect that standard to be there so you can move from compiler to compiler, platform to platfom, and expect the same behavior--not of course including non-standard features. commerical Fortran compilers support the standard. commerical Lisp compilers do too. why is it that commerical C++ compilers can't?
i'm not saying it's easy or that i could do it, but if M$ can pump $$$$$$$$$$$ into a single platform Java ripoff development environment then they can at least support a little linker problem....
:)
vBulletin® v3.7.0, Copyright ©2000-2009, Jelsoft Enterprises Ltd.