VC++ LNK2019 Error I can't seem to fix

Question

So I was writing, as a small project, a stress test. Initially, to save time, I just plopped code in a header file. I decided to organise it a bit, and moved everything to a .cpp file and then wrote the header file, but VS2010 presented me with an LNK2019 that I can't seem to fix.

FSTRESS.cpp (Didn't include code, because I doubt it is relevant; ask if you need it)

FSTRESS.h

Main.cpp

The error:

    error LNK2019: unresolved external symbol "public: static void __cdecl FSTRESS::Start(unsigned int,unsigned int,unsigned int)" (?Start@FSTRESS@@SAXIII@Z) referenced in function _main  C:\Programming\C++\FLOPS_Test\FSTRESS\FSTRESS\main.obj  FSTRESS_Mk.II

Any ideas on why this is happening? I'm a bit of a C++ noob. Thanks for any help :)

Answer 1

So, you've actually got two separate definitions of the x86 and FSTRESS classes, one in the header file and one in the .cpp file. You're allowed to do that provided that the definitions are identical, but they aren't -- the one in the .cpp file has a bunch of inline code, which isn't there in the one in the header file. (Look up "one definition rule" for more information about this.)

What you actually want to do is this. Your header file is fine (or, at least, I don't see anything conspicuously wrong with it). The .cpp file should (1) #include the header file, and then (2) provide definitions for the member functions, looking like this:

static void FSTRESS::Start(unsigned aMode, unsigned aTest, unsigned aThreads) {
  // code goes here
}

(When you have a source file and a corresponding header file, the source file should always #include the header file. This helps to make sure that if there's an inconsistency it gets caught tidily at compile time. I can't tell whether you were already doing that because the top of FSTRESS.cpp is invisible in your screen captures. It might have been better to post the code as text :-).)

As an aside, don't use names that begin with an underscore. A large portion of the space of such names is "reserved", meaning that the C++ implementation can use them internally and Bad Things can happen if your use clashes with its use. It's best just to avoid them all, because that way you don't have to remember what the exact rule is and neither does anyone else reading your code.