Probably A Stupid Question

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

Code:

---

// myclass.h

class myClass
{
public:
  myClass (void);

private:
  int x;
};

---

Code:

---

// myclass.cpp

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

---

Code:

---

// 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?

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

Code:

---

#include "myclass.cpp"

---

I heard it was bad practice to include source files.

I mean, I heard:

Code:

---

#include "x.cpp"

---

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

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.

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

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.

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.

Code:

---

// 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;
}

---

Excellent - thanks a lot!

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?

Code:

---

// 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.

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

Quote:

---

Originally Posted by 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

---

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.

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).

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

Identifiers with a leading underscore followed by an upper case letter and identifiers with a double underscore anywhere are reserved for the implementation, so its best not to use them just in case the implementation is using them. Many people recommend never using leading underscores at all just to be consistent.

Quote:

---

Originally Posted by 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).

---

Why don't you include a cpp file? I've always been taught to. Plus doesnt the compiler just copy the code from the .cpp into the .h before adding that to the client?

No. Each cpp file is compiled separately into an object file. The object files are then linked together by the linker. If you include all the cpp files into a single source file, then every time you change the implementation of one of your classes you have to recompile the entire thing. One of the biggest reasons for separate header and source files is so that the compiler can compile code based on the interface presented in another header file without having to know how that interface is implemented. That way you can change the implementation of a single class, and only that source file needs to be recompiled and the object files re-linked.

When you have thousands of source files this makes a huge difference. When you only have a couple it is still the right way to go.

I believe that some people might have taught to include cpp files as a way of getting around adding each source file to a project or make file, but it is bad advice.

Hmm thats really interesting, I dont usually make projects with my files so I guess I've never really thought of it.

Do not include *.cpp files!

It is a bad habit which violates the premise of separating the definitions from the declarations.

Instead, include the headers in the source files. Then, make sure that you compile your code (without linking, creating an intermediate object file). Then, the object file will be linked. Dae and Daved already mentioned the easiest way to do this.

*edit*
Alright, I didn't see the second page. Sorry for the duplication here.

And how do you create an "intermediate object file"? is it truely THAT bad? will it slow down the program or make it have incorrect results?

From what I can see, if you are only using 1 file as your Project, then only 1 object file is being created. Meaning its all in one big file.

One point of object files is so that you can seperate large projects where maybe you only update 5/30 of the files, so only 5/30 of the object files have to be recompiled and therefor wont take 2 hours to compile.

Another point is that it seems if you changed one of the .cpp files (thats included in the .h file), it will not update when you compile, because it skips the compiling process. The compiling process is skipped because it skips recreating the object file unless the .cpp file thats in the Project list has changed, which it may not, but one of the other 'somehow included' .cpp files could have. This would result in an object file not being as updated as one of the actual files, and therefor incorrect results.

Another point is that when using an IDE is it makes the object file for the .cpp (and gives you errors) then goes to the next .cpp file, this means it can catch any errors from 1 of the many files before finishing the compiling process so you dont waste 1-60 minutes compiling one large object file to find your errors.

Doing it should effect how the linking goes because the point of .h is for declarations.. in the compiling process it does not need to know that the value is, but that it exists, which is the point of the .h. I'm unsure but I also think it could result in problems using the extern keyword.

Ok I see what you guys are saying, but in my current coding situations where I dont even create projects (unless coding win32 api) and instead link like 2-5 (small-medium) headers it doesn't take long to compile the whole thing. But thats a really good idea, thanks guys.

So how does one go about implementing a make file in MSVC++ 6.0?

It's easier to just use a project in VC++. Under the Project menu select Add To Project and use New... to create a new, empty file or use Files... to add existing files to the project. You can add your header and source files, and VC++ will know to compile the source files and just keep track of the header files.

So every new file that you write you should add to your project. As long as one and only one of the source files has a main function, when you hit Build (F7) it will work.

Quote:

---

. . . and of course put an #ifndef/#define/#endif in that .h . . .

---

Yesterday I would have agreed with you. But today I read a C book and it said that #ifndef was not recommended and that you should use #if !defined() instead. However, I don't know why this is. Does anyone else?

Apparently you can use a 'defined' operator with an #if, and not an #ifndef, so that could be why. However I dont see what use using 'defined' will gain you in C++. I can see how it could POSSIBLY be useful in C because you use many macros in C, but if you are only using macros for .h file data, then I doubt theres a 1/10000 situation possiblity that you would want to 'defined' in C++. What it does:

Code:

---

#if  defined (macro1)  || !defined (macro2) || defined (macro3)
printf( "Hello!\n" );
#endif

---

See you generally dont decided, hell, if this .h file is defined lets not include this code (why even have this code then?).

Unless.. well, wait, this would probably be really useful for OpenGL where you're programming for cross-platforms. You #define which platform you are compiling for, then have the .h files that have the code for either windows, linux, solaris, or mac os say #if defined listing all the other platforms with || operator, basicly saying "if any other platform is defined, then I am not" which would make it easier for keeping a project together, and easily changing for which platform you want to compile.

Is that one of the reasons? and anyone know if theres more, for C++ (theres probably more for C than C++).

Quote:

---

. . . I dont see what use using 'defined' will gain you . . .

---

Neither do I. Just something I read, and wondered about.