Probably simple problem with classes

It's been a while since I've used c++ much and now I'm enountering an annoying problem. It's probably some simple syntax issue (either that or the compiler is broken, but it's never really that.. :) ). I've looked over various things and I can't see what's wrong....I think I'm just too involved at this point and I need a second opinion.

The problem is that the linker can't seem to find any methods within the class. I'm using gcc 2.95 and I 3.1....I get the same thing with both.

The errors are:

testy.cpp: undefined reference to `test::test(void)'
testy.cpp: undefined reference to `test::nowork(void)'

(I trimmed off the full path)

This is my code:

test.h

Code:

---

class test {
  public:
      test();
      void nowork();
};

---

test.cpp

Code:

---

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

using namespace std;


test::test() {
}

void test::nowork() {
  int useless;
  cout << "hi there!\n";
}

---

testy.cpp (driver)

Code:

---

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

int main() {
 
  test will;
  will.nowork();
}

---

Any help you can give would be appreciated, thanks.

Nevermind to what Thantos said.

I'm willing to bet you are forgetting to link in test.cpp (or the equivlent .o file)

Using your code (and commenting out the unused variable) I was able to compile and run using the following:

Code:

---

g++ -o test test.cpp testy.cpp

---

Quote:

---

Originally Posted by 7smurfs

You have no prototype of the functions in testy.cpp.

...

Code:

---

class test {
  public:
      test();
      void nowork();
};
void nowork(void);

---

Now testy.cpp has a prototype and a definition of nowork().

---

This is wrong. The prototype for nowork already exists inside the test class declaration. Adding an extra prototype outside the class does prototypes a completely separate function that is not being defined or used anywhere.

Quote:

---

Originally Posted by jlou

This is wrong. The prototype for nowork already exists inside the test class declaration. Adding an extra prototype outside the class does prototypes a completely separate function that is not being defined or used anywhere.

---

Alright thats it. I'm burning this $%^# book and buying one that knows what its talking about.

Oh just a personal opinion comment:

Code:

---

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

---

You should put all user defined header files after all of the standard header files as such:

Code:

---

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

---

The reason for that is then if there is a parse error at the end of your header file then it won't be "caught" inside of the standard header file. Given the size of the standard header files the number of cascading errors caused by a parse error can be a lot (several screen fulls). I speak this from personal experience.

Also it helps in keeping all your user defined header files together. In reality these header files are more important for understanding your code. Yes the standard header files are important to include but anyone with some experience under their belt will know which standard headers are needed just by reading your code. By grouping all the user defined headers (and using good names) I'll know where to look when I see a user defined type or function.

Just my 2 cents.

I knew It'd be something simple. It works just how you said. I went over and over my syntax and it never occurred to me to think that maybe I wasn't actually using the compiler correctly....I was only compiling the driver file. For some reason I was thinking that it would go out and compile the other, though looking back on it I can see how that makes no sense :) I feel like I know too little about too many languages. I just finished a class where we used python which, come to think of it, would explain why I was thinking totally backwards because the python interpreter does behave in the way I was thinking g++ would behave (though of course it isn't actually compiling anything). Of course that was my real problem.. I thought. I haven't really used c++ more than a little in the last couple of years. It'll all come back eventually.... :)

I also recall seeing the convention of putting user defined headers second at some point or another, though I had no idea why it was good practice. I'll keep that in mind.

Thanks for all your help.