unresolved external error...???

For some reason when this code gets include i get weird linker error......

here's main function:..

Code:

#include <iostream.h>
#include "ItemManager.h"


int main()
{
  ItemManager SomeItem;
  SomeItem.ItemCreate();

  return 0;


}

here's what the linker is flagging...

[Linker Error] Unresolved external 'ItemManager::ItemCreate()' referenced from C:\PROGRAM FILES\BORLAND\CBUILDER5\PROJECTS\INVENTORY\MAIN2.O BJ

just for reference here's the code for ItemManager.h.....

Code:

//----------------------------------------------------------------------------
// Preprocessor directives...

 #ifndef ITEMMANAGER_H
 #define ITEMMANAGER_H

//-----------------------------------------------------------------------------
// class ItemManger

 class ItemManager
  {
    public:

           void ItemCreate();


  };

//-----------------------------------------------------------------------------

 #endif

i can't spot the problem....the code compiles fine... linker is the only objective part...

Thanx in adnvance....

matheo917

Code Fixed:

Code:

#include <iostream.h>

#ifndef ITEMMANAGER_H
#define ITEMMANAGER_H

struct someitem
{
  int itemcreate;
};

int main()
{
  someitem.itemcreate;

  return 0;


}

That should work

Where's ItemManager.cpp?

Code:

void ItemCreate();

This is a function prototype, not a declaration. You cannot call it before defining it.

ItemManager.cpp is in a separate file.. i didn't include it in this post....

so far i figured out that when ItemCreate() function is implemented in a separate file that's when that unresolved external error occurs.... i wonder why?

does itemmanager.h #include "itemmanager.cpp" at the bottom?

hmmm.....no it doesn't include anything on the bottom... what do you mean?? that's the first time i hear about this...

???

Well then that is your problem.

Here is the deal on class files:

There are two files. An interface (.h) and an inplementation (.cpp).

The interface file contains all the function declarations, basically what you would normally find above the int main in a primary file. It might also define a few constants. It is heavily commented, and meant for users of that class to look at. It generally contains no code, no algoriths or anything like that, that is in the implementation file.

The implementation file is where a class' guts are. All the previously declared functions must be defined, that is, they must be coded.


Now, to use a class in a program, the .h file is #include'd at the top. I see you have done that.

However, the (.h) file alone is not enough for the class to function. You need the definitions. So, at the very bottom of your .h file, just above the #endif, you need to #include your .cpp file, so the program will have access to those definitions.

thank you..........it woooooorks....
i am beat...... such trivial thing and yet gives me a lot of headaches....

hope that reference i posted helped you..

Regards,
matheo917

That's the first time I've ever heard of doing that. Is that Borland specific? I use MSVC 6.0, learned mostly from Deitel's text, never seen #including .cpp's or #includes at the bottom.

Nope, its the language.

The only time you would need to do it is if you wrote your own class and then compartmentalized it into it's own files. That is probably why you haven't seen it.

Alternatively, if you have taken AP computer science, like alot of people on this board, myself included, have or are, you will have been exposed to the less preferred style of #including the .h at the top of the .cpp and then #including the .cpp in the main program. The case study uses these type of files, although they are considered bad form.

Actually, the way I've seen it (see Deitel) is to #include the .h file in the .cpp implementation file, then #include the original .h file in the file with main().
MSVC puts this stuff in a project, or workspace, so maybe it compiles together that way. Never seen your way. Sometimes I mix up w/Java though.

Well I don't use msvc, and I'm not exactly familiar with the preprocessing commands, but I am pretty sure the "projects" method is an implementation-defined method of using multiple source files.

The language itself has no notion of a project. I think the diff is that projects are all compiled separately and then brought togther by the loader(linker) whereas the Standard-defined method of using preprocessor directives causes the files to be included by the preprocessor before compilation, then all compiled into one big object file. I prefer the Standard's method, because using project files makes your code needlessly implementation-dependant.