C++ question about multiple cpp files

[elzmaddy]

Hi all, I'm just trying to do something very simple with C++. Instead of writing my code in one large file, I want to break it up into multiple files. Let's say I have two files, file1.cpp and file2.cpp. This is file1.cpp:

#include <iostream>
#include <vector>
#include <fstream>
#include <string>

using namespace std;

#include "file2.cpp"

int main()
{
return 0;
}


So what do I need to put at the top of file2? How can I make sure file1 is compiled and executed first? The compiler is giving me like 20 errors regarding File2, which is actually flawless. It seems it cannot find the #include lines from file1. How can I correct this? You can tell me the answer in dev c++ or Microsoft VC++. I will use whichever one I can figure this out in. Got a huge project due soon, Thanks for any help!!

 

[Barnaby W. Füi]

You should make file1.h and file2.h and put the declarations in them. Then you include whatever .h files you need in the other files. You then compile each .cpp into an object, and link them together by hand so to speak, at the end.

But as for how to do it in vc++, I couldn't tell you. (heh, I couldn't even tell you specifically how to do with with gnu tools unless you gave me a couple minutes to look )

 

[elzmaddy]

Totally not getting you

This is as close as I can get: When I create a new project in dev, it starts me off with a main.cpp that include declarations and the main function. Now, I can add a new file, let's say I call it blah.cpp which contains only this function:

void blahblah()
{
cout << "blah blah blah";
}

If I 'Compile and Run' the project, it says that cout is not defined (but it is in the main.cpp via the #include line). I also checked project properties, both files are included for linking and compiling.. So why can't I do this??

 

[Barnaby W. Füi]

Something like this:

-----file1.h-----
int main();
------------------

-----file1.cpp------
#include <iostream>
#include "file1.h"
#include "file2.h"

using namespace std;

int main() {
cout << "hi" << endl;
blah();
return 0;
}
-----------------------

-----file2.h---------
void blah();
----------------------

------file2.cpp---------
#include <iostream>
#include "file2.h"

using namespace std;

void blah() {
cout << "blah" << endl;
}
---------------------------

 

[elzmaddy]

It worked, thanks for the help. Seems a somewhat complicated solution though.

So for each class/function/etc I have in my file2.cpp I will have to define it in my file2.h, and same for file1's right?

 

[dighn]

Originally posted by: elzmaddy
It worked, thanks for the help. Seems a somewhat complicated solution though.

So for each class/function/etc I have in my file2.cpp I will have to define it in my file2.h, and same for file1's right?

not all of them. for each function/class/variable in file2.cpp that you use in other files, you need to declare them. you don't have to declare the ones you don't use in other files.

if your program is really short and simple, you can give up the .h files and just declare what you use inside the .cpp eg:

file2.cpp:

void foo(int i)
{
...
}

file1.cpp:

void foo(int i);

int main()
{
blah blah
}

 

[TerryMathews]

If this helps you any:

When you #include a file (this includes headers like <string> which means something different beyond the scope of this post), you are in essence telling the compiler to cut and paste that file into that location in the source you're working in.

That always helped me immensely to determine what can/should be put into another file.

 

[elzmaddy]

When you #include a file (this includes headers like <string> which means something different beyond the scope of this post), you are in essence telling the compiler to cut and paste that file into that location in the source you're working in.

That is what I want, but I could not find a way to get it to work this way.

I got it to work with my program by applying dighn's and BingBongWongFooey's advice. The trick is not to use #include for cpp files. I put together two cpp files and this is the format:

file1.cpp

#include <iostream>

// declare the functions/classes you are using in THIS file here
// now declare the functions/classes you are using from the OTHER file here

using namespace std;

// ...etc.....

file2.cpp

#include <iostream>

// here you just declare the classes/functions in this file.

using namespace std;

//... etc...


Thanks all, Now I don't have to scroll through one very long file

 

[Descartes]

Originally posted by: elzmaddy

When you #include a file (this includes headers like <string> which means something different beyond the scope of this post), you are in essence telling the compiler to cut and paste that file into that location in the source you're working in.

That is what I want, but I could not find a way to get it to work this way.

I got it to work with my program by applying dighn's and BingBongWongFooey's advice. The trick is not to use #include for cpp files. I put together two cpp files and this is the format:

file1.cpp

#include <iostream>

// declare the functions/classes you are using in THIS file here
// now declare the functions/classes you are using from the OTHER file here

using namespace std;

// ...etc.....

file2.cpp

#include <iostream>

// here you just declare the classes/functions in this file.

using namespace std;

//... etc...


Thanks all, Now I don't have to scroll through one very long file

You are correct about not using includes for source files (translation units). This should never be done.

I think there's a bigger problem with the above, however. Why are you splitting up the two source files? Are you doing so logically, or are you doing so arbitrarily? In other words, do you feel the two source files represent a logical decomposition of functionality, or are you separating them simply because it would otherwise be too long?

I don't understand the motivation of separating them into separate files unless it's insanely long. How long is this file? The fact that you have File1 and File2 is highly indicative of a problem; the names mean absolutely nothing. A given translation unit should be functionally coupled to the semantics of the name. For example, main.cpp would contain the insertion point of the application, and network.cpp would logically contain sockets-related code. File1 and File2 is an arbitrarily decomposition of code. If you break it up arbitrarily and add a bunch of externs to one of them it will make the code much harder to read, imo.

If you do decide to decompose the two files based on functionality, then each file would have its own header file to be included. This would make the code easier to read.

Anyway, that's my tupence. I firmly believe that you will find that a given translation unit can be decomposed into functionally-cohesive units before it even gets close to being too long.

 

[elzmaddy]

You are correct about not using includes for source files (translation units). This should never be done.

I think there's a bigger problem with the above, however. Why are you splitting up the two source files? Are you doing so logically, or are you doing so arbitrarily? In other words, do you feel the two source files represent a logical decomposition of functionality, or are you separating them simply because it would otherwise be too long?

I don't understand the motivation of separating them into separate files unless it's insanely long. How long is this file? The fact that you have File1 and File2 is highly indicative of a problem; the names mean absolutely nothing. A given translation unit should be functionally coupled to the semantics of the name. For example, main.cpp would contain the insertion point of the application, and network.cpp would logically contain sockets-related code. File1 and File2 is an arbitrarily decomposition of code. If you break it up arbitrarily and add a bunch of externs to one of them it will make the code much harder to read, imo.

If you do decide to decompose the two files based on functionality, then each file would have its own header file to be included. This would make the code easier to read.

Anyway, that's my tupence. I firmly believe that you will find that a given translation unit can be decomposed into functionally-cohesive units before it even gets close to being too long.

Good points, the file names were just for example. They actual file names are related to specific sections of the tic-tac-toe game I am to create, using a backtracking design. The professor wants three files, one for the general backtracking classes, the next for classes to implement backtracking in tic tac toe game, and a third for the "test area."