Including .Cpp Files

Including .cpp files

What include does is copying all the contents from the file (which is the argument inside the <> or the "" ), so when the preproccesor finishes its work main.cpp will look like:

// iostream stuff

int foo(int a){
    return ++a;
}

int main(int argc, char *argv[])
{
   int x=42;
   std::cout << x <<std::endl;
   std::cout << foo(x) << std::endl;
   return 0;
}

So foo will be defined in main.cpp, but a definition also exists in foop.cpp, so the compiler "gets confused" because of the function duplication.

When do I need to #include .cpp files?

Using #include somefilename means that content of somefilename is put in place of the include.

By putting #include "LineType.cpp" in your Driver.cpp file you efectively put everythig in one file and then compiling using g++ Driver.cpp works fine for you.

When your instructor used IDE for compiling it went on separate compile and linking. So it compiled Driver.cpp and LineType.cpp Both files contain definitions from LineType.cpp due to that include. So when it came to linking, she had everything definded in LineType.cpp twice and linker didn't know what to do.
You can compile and link multiple files at once by using

g++ Driver.cpp LineType.cpp 

Or using separate compile and linking commands

g++ -c Driver.cpp
g++ -c LineType.cpp

Which will generate files Driver.o and LineType.o. Then you can combine them together by running

g++ Driver.o LineType.o

How do I include other .cpp files

Your program is working as can be seen here.

To get your program working on your machine follow these steps(assuming you're using g++ and Ubuntu:

Step 1: Create a binary/executable using the command:

g++ main.cpp Header.cpp -o myexecutable

Step 2: Test/Run your executable created in the last step using the command:

./myexecutable

Alternate Solution: A shortcut

Now if you're wondering that you've to type the name of every source file to make the executable, then you can take a sigh of relief because there is a shortcut as given below:

Assuming you have many source files(.cpp files) in your current directory and you want to compile them all without writing the names of all of them, then you can use the command:

g++ ./*.cpp -o myexecutable

The above command will create a binary/executable named myexecutable .

Include a *.cpp file

The normal workaround is to put includable cpp files in the textual_hdrs attribute of cc_library.

Can only compile and run when including .cpp file

You include the header file, so prototypes are available, and the compiler does not complain. The linker needs to find the source associated with those functions. Using g++ -std=c++11 LinkedList.cpp -o LinkedList.exe to compile means that you're only using the main file source and not the other file that contains the linked list implementation.

The solution is to also pass the SingleNode.cpp file to the compiler. Hence:

g++ -std=c++11 LinkedList.cpp SingleNode.cpp -o LinkedList.exe and include the SingleNode.h file in LinkedList.cpp.

The #include directive performs textual substitution, which means that when you include the .cpp file(which, in turn, includes the header file) you have one final translation unit that contains the required source of both source files.

Also see: Why should I not include cpp files and instead use a header?

Why should I not include cpp files and instead use a header?

To the best of my knowledge, the C++ standard knows no difference between header files and source files. As far as the language is concerned, any text file with legal code is the same as any other. However, although not illegal, including source files into your program will pretty much eliminate any advantages you would've got from separating your source files in the first place.

Essentially, what #include does is tell the preprocessor to take the entire file you've specified, and copy it into your active file before the compiler gets its hands on it. So when you include all the source files in your project together, there is fundamentally no difference between what you've done, and just making one huge source file without any separation at all.

"Oh, that's no big deal. If it runs, it's fine," I hear you cry. And in a sense, you'd be correct. But right now you're dealing with a tiny tiny little program, and a nice and relatively unencumbered CPU to compile it for you. You won't always be so lucky.

If you ever delve into the realms of serious computer programming, you'll be seeing projects with line counts that can reach millions, rather than dozens. That's a lot of lines. And if you try to compile one of these on a modern desktop computer, it can take a matter of hours instead of seconds.

"Oh no! That sounds horrible! However can I prevent this dire fate?!" Unfortunately, there's not much you can do about that. If it takes hours to compile, it takes hours to compile. But that only really matters the first time -- once you've compiled it once, there's no reason to compile it again.

Unless you change something.

Now, if you had two million lines of code merged together into one giant behemoth, and need to do a simple bug fix such as, say, x = y + 1, that means you have to compile all two million lines again in order to test this. And if you find out that you meant to do a x = y - 1 instead, then again, two million lines of compile are waiting for you. That's many hours of time wasted that could be better spent doing anything else.

"But I hate being unproductive! If only there was some way to compile distinct parts of my codebase individually, and somehow link them together afterwards!" An excellent idea, in theory. But what if your program needs to know what's going on in a different file? It's impossible to completely separate your codebase unless you want to run a bunch of tiny tiny .exe files instead.

"But surely it must be possible! Programming sounds like pure torture otherwise! What if I found some way to separate interface from implementation? Say by taking just enough information from these distinct code segments to identify them to the rest of the program, and putting them in some sort of header file instead? And that way, I can use the #include preprocessor directive to bring in only the information necessary to compile!"

Hmm. You might be on to something there. Let me know how that works out for you.

---

Related Topics