Probably A Stupid Question

[samGwilliam]

One thing I've never got my head around is multiple file projects. For example:

// myclass.h

class myClass
{
public:
   myClass (void);

private:
   int x;
};

// myclass.cpp

myClass::myClass (void)
{
   x = 0;
}

// mymain.cpp

#include <iostream.h>

#include "myclass.h"

int main (void)
{
   myClass m;
}

I cannot get a simple project like this to execute. I am using MSVC 6.0 and I add myclass.cpp to the Source Files folder but the class cannot be seen properly - I get errors such as "myclass.cpp: myClass is not a class".

There is no "Cannot find 'myclass.h'" error so the header file can be seen but it seems like it's just being ignored.

How do you put a simple multi-file project together?

[JoshR]

in myclass.h put at the end of your code:

#include "myclass.cpp"

[samGwilliam]

I heard it was bad practice to include source files.

[JoshR]

Nope, I've read many books / tutorials and apcs class packets that state that its good practice to have them in seperate files so the prototypes can be seperate from the definitions for client ease of use. If they are in seperate files you MUST include them or the compiler would have no way to link them.

[samGwilliam]

I mean, I heard:

#include "x.cpp"

...would be wrong. Is it something to do with the extern keyword or make files?

[JoshR]

No thats perfectly fine, but I know what your talking about...You mean that you shouldn't include cpp files in your main cpp. It is a necessity to include them in your header though or it won't link. you dont need extern here or make files. Just add the #include "myclass.cpp" in myclass.h trust me, you can look it up on google if you want. I've seen some examples on the internet

[Dae]

Its because you have both .cpp's part of your Project List right? (both .cpp's should be in the Makefile). Therefor you will need #include "myclass.h" in myclass.cpp. That should work, and of course put an #ifndef/#define/#endif in that .h for safety.

[JoshR]

Well for client ease of use, its stated that its easier to include the prototypes (myclass.h) in the client app and have myclass.h include myclass.cpp so the client doesnt have to see the code behind the declerations.

[JoshR]

// myclass.h
#ifndef MYCLASS_H_
#define MYCLASS_H_

class myClass
{
public:
   myClass (void);

private:
   int x;
};

#include "myclass.cpp"

#endif

----------------------------------------------------
// myclass.cpp

myClass::myClass (void)
{
   x = 0;
}

-------------------------------------------------------
// mymain.cpp

#include <iostream.h>

#include "myclass.h"

int main (void)
{
   myClass m;
}

[samGwilliam]

Excellent - thanks a lot!

[Dae]

myclass.cpp needs to know the declarations (thats the .h code) and so must mainclass.cpp (by including the .h) but the mainclass.cpp wont know the definitions when compiling by just including the .h (even if its in the same project list) until it gets to the linker. This wouldnt give the definitions prehand so whats wrong with it again?

// myclass.h
#ifndef _MYCLASS_H_
#define _MYCLASS_H_

class myClass
{
public:
   myClass (void);

private:
   int x;
};

#endif

----------------------------------------------------
// myclass.cpp

#include "myclass.h"

myClass::myClass (void)
{
   x = 0;
}

-------------------------------------------------------
// mymain.cpp

#include <iostream.h>

#include "myclass.h"

int main (void)
{
   myClass m;
}

EDIT: if it isnt seeing the code behind the declarations (myclass.cpp) when compiling, then if you are using Dev-Cpp /etc it will not know to update the .object file, and therefor will not be using an updated version of myclass.cpp. I tested. I changed x to 5, and it still said it was 0.

[JoshR]

When the compiler includes the .h in your example code Dae there is no refference to myclass.cpp so it wont include it. Its better for a client to include .h in the main.cpp and not the .cpp of the class

[Dae]

When the compiler includes the .h in your example code Dae there is no refference to myclass.cpp so it wont include it. Its better for a client to include .h in the main.cpp and not the .cpp of the class

Isnt that what a Project List, or Makefile is for? you include the .cpp in your Makefile, and the .h's in your .cpp's, which solves all problems.

[Daved]

JoshR, you should never #include a cpp file. The only potential exception is when you work with templates, and even then there are other solutions.

As Dae says, the proper way to do it is to add each cpp file to your project or makefile. Use Dae's example for the proper way to setup multiple source files (with one minor change - don't use leading underscores followed by an uppercase letter, just remove that leading underscore from the _MY_CLASS_H_ part).

[Dae]

No leading underscore? is it because the standard files contain leading underscored defines/variables? ahh that would make sense.