Thread: Unresolved External? Help!

I'm getting the following error when compiling my program:

(Visual Studio Error):

1>tictac.obj : error LNK2019: unresolved external symbol "protected: void __thiscall BasList::remove_node(class ListNode *,int,int)" (?remove_node@BasList@@IAEXPAVListNode@@HH@Z) referenced in function "public: void __thiscall BasList::remove_head(int,int)" (?remove_head@BasList@@QAEXHH@Z)

(And here it is in GCC, in case that helps too):

/tmp/ccYrl06E.o: In function `BasList::remove_head(int, int)':
tictac.cpp.text._ZN7BasList11remove_headEii[BasList::remove_head(int, int)]+0x25): undefined reference to `BasList::remove_node(ListNode*, int, int)'

Bahhh, why doesn't it give a line number. I don't know what it's referring to since I don't see those functions linked in my main anywhere.

How do I find out where the error is?? Can't double click it =\

----------


If you want to check out the source code, all I'm trying to do is compile this tic tac toe game: http://www.cs.ucsb.edu/~cs165a/Softw...imaxGuide.html

(All code is downloadable via the "AI Library" zip file http://www.cs.ucsb.edu/~cs165a/software.html )

In the zip file, the only files I'm using are tictac.h, tictac.cpp, minimax.h, xlist.h, and blist.h. Try to compile and you'll get a bunch of linker errors

Anyone have any ideas?

Originally Posted by Paul22000

In the zip file, the only files I'm using are tictac.h, tictac.cpp, minimax.h, xlist.h, and blist.h. Try to compile and you'll get a bunch of linker errors

Anyone have any ideas??

Yes, you need to add another source file(s) to your project. At the very least, blist.cpp would appear to be needed as well.

It looks like blist does have a source file:

Code:

$ find -name 'blist*'
./AILibNix/include/blist.h
./AILibNix/util/blist.cc
$

I'd compile with it if I were you.

The methods that don't have a body (in curly braces) in blist.h need to be found elsewhere, and hopefully blist.cc gives you them.

While we're here, what do you think about this warning:

gets() is the most poorly designed function in the entire C runtime library. Avoid it like the plague.

Originally Posted by Paul22000

Bahhh, why doesn't it give a line number. I don't know what it's referring to since I don't see those functions linked in my main anywhere.

It isn't giving a line number because it's a LINKER error, not a COMPILER error. Having said that, building in debug mode will often allow the linker to report an exact line number, but not all linkers will do that. You might try it at least.

Originally Posted by Paul22000

Is there something better to replace it with than get_s?

fgets(buffer, size, file) will do the essentially the same thing as gets, but safely if you give it stdin as the last argument, and the size of the buffer as the middle argument. The main difference is that the newline ('\n') corresponding to the enter-key is in the buffer, so you may need to remove that. If there is no newline at the end of the input you received, the input was longer than your buffer, and you would want to call fgets() or getchar() repeatedly until you get a newline.

--
Mats

When you create a new project, it compiles in debug mode by default. So apparently the linker just isn't smart enough.

Sure, that works. You could make it a little more maintainable with

Code:

fgets(answer, sizeof answer, stdin);