Curiosity: including .cpp files

[Mr_Miguel]

This isn't related to any problem I'm having, but I'd like to understand this issue once and for all.

When people do something like:

#include "myfile.cpp"

I often see replies saying "you can't include .cpp files. Only header files!"

I beg to differ. Here's a little example I prepared:

hellomain.cpp code

#include <iostream>
#include "helloworld.cpp"

using namespace std;

int main() {
  helloWorld();
  cin.get();
  return 0;
}

helloworld.cpp code

#include <iostream>
using namespace std;

void helloWorld();

void helloWorld() {
  cout << "Hello World!" << endl;
}

Assuming both .cpp files lie in the same directory, I can compile and execute hellomain.cpp just fine! I don't even need to create a project file in Dev-C++ for this to work!

So the question is... Is there something I'm missing? Why exactly do people say we can only include header files? Is it something else I should know?

Looking forward to your replies.

[anon]

#include just copies and pastes code for the compiler. In this case it will work, but in a real application where you might want to use HelloWorld() in multiple source files, you'll get multiple definition and possibly other errors.

Anyway, including cpp files would also mean that the order in which and where the file is included matters. So far I have managed to write almost all projects so that this doesn't matter.

[laserlight]

It is by convention, with the exception that templates might be divided into a header file and "implementation" file, with the latter included in the former.

This is typically because function and class declarations are placed in header files with a ".h" (or ".hpp") extension, and the implementations of these functions and classes are placed in files with a ".cpp" (and other) extensions.

[indigo0086]

You can but you shouldn't. You should want to separate implementation and declaration by using the .h and .cpp files seperately, and only including the .h files when necessary. The compilation and linking process ensures that if code from an included header file is needed, it is linked into the executable. Why do something the linker does for you?

[swgh]

Header files as a genreal rule should only include class and function definitions along with the suitable header gaurds for that file. They should not include any "working" C++ code.

ie: std::cout << "Hello\n";

The header file is then included into the project at the point it is needed. (usually the corrisponding .cpp file that holds the implementation for the class in the header file )

[Mr_Miguel]

#include just copies and pastes code for the compiler. In this case it will work, but in a real application where you might want to use HelloWorld() in multiple source files, you'll get multiple definition and possibly other errors.

Anyway, including cpp files would also mean that the order in which and where the file is included matters. So far I have managed to write almost all projects so that this doesn't matter.

Now I see your point. I have slightly changed my example. Normally, one would put all three files in the same directory and compile:

g++ -Wall hellomain.cpp helloextra.cpp -o helloworld.exe

(helloworld.cpp wouldn't be needed, since it's already included in hellomain.cpp)

But you're right. I get a multiple definition error if I do that.

You see, the reason I asked this is mainly because of compilers such as gcc and g++. The conventional way requires you to put all .c or .cpp files in gcc or g++, like so:

g++ -Wall hellomain.cpp helloextra.cpp helloworld.cpp -o helloworld.exe

where the three .cpp files would only include function implementations and not function prototypes. For the prototypes, one would (possibly) have to create three additional files - hellomain.hpp helloextra.hpp and helloworld.hpp with those prototypes. But then I thought: "Why do we programmers have to bother with separating function prototypes from the actual function implementations? Wouldn't it be more convenient to just store them all in single files rather than two files each?"

Really, it kind of sucks. My approach would definitely work if g++ discarded multiple definitions of functions, but I guess I'll just have to be content with what I got...

[Perspective]

>discarded multiple definitions of functions

And how would it know which one to keep? This error is no different than if you actually declared the same function multiple times.

[Mr_Miguel]

>discarded multiple definitions of functions

And how would it know which one to keep? This error is no different than if you actually declared the same function multiple times.

Wouldn't matter in this case. helloWorld() has the exact same code on both definitions. I'd like the compiler to just pick one definition and throw the rest of them away. Another way would be to check the actual code of the definitions - if the code were equal, keep one of them; if one definition had different code, show an error or something.

For example:

//A definition
helloWorld() {
  cout << "Hello World!" << endl;
}
//Another definition (duplicate)
helloWorld() {
  cout << "Hello World!" << endl;
}

No differences between both helloWorld() functions here, right? Just discard one and everything will be just fine.

Another example:

//A definition
helloWorld() {
  cout << "Hello World!" << endl;
}
//Another definition - this one doesn't have the ! at the end
helloWorld() {
  cout << "Hello World" << endl;
}

Whoopsey! There's a difference between both. Now this is where I'd like to be "greeted" with an error message.

But, like I said, I doubt g++ has a flag for this, so I might reconsider my programming style in C++. It's no big deal, really. If I have to pay the price of separating functions from their prototypes to use C++ effectively, so be it. Everyone has to pay certain prices when they choose a programming language, right?

[laserlight]

Wouldn't matter in this case. helloWorld() has the exact same code on both definitions. I'd like the compiler to just pick one definition and throw the rest of them away. Another way would be to check the actual code of the definitions - if the code were equal, keep one of them; if one definition had different code, show an error or something.

In the first place, having such duplicate code probably means that you are not thinking right, or were careless. That the compiler tells you sooner about the potential problem instead of later is a Good Thing, in my opinion.

Consider the likelihood that two non-trivial functions would be identical. I think that it is not worth the trouble trying to do that kind of duplicate code elimination when most of the time that it happens, you have to resolve it manually anyway.

[CornedBee]

Don't use simple command lines for compiling. Use a Make-like program like Make itself, SCons, bjam, any of those work very well and the compilation is reduced to invoking the build process as "make" or "bjam" or "scons".

[Mr_Miguel]

Don't use simple command lines for compiling. Use a Make-like program like Make itself, SCons, bjam, any of those work very well and the compilation is reduced to invoking the build process as "make" or "bjam" or "scons".

Doesn't solve my problem. I'd still have to separate prototypes from implementations. Sorry, but my point still stands. I apologize if I'm being annoying, but I just can't help it - I hate separating prototypes from functions. Yes, despite the fact that it's the conventional way. Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes! I don't know about you, but in my opinion, it looks ugly.

I know that most of you on this board strongly supports that we should follow the conventions at all costs. But I strongly believe that I do have a point. It's just my opinion. Please don't hate me for it. It's not my intention to make enemies on this message board.

Thank you all for your help.

[vart]

Doesn't solve my problem. I'd still have to separate prototypes from implementations. Sorry, but my point still stands. I apologize if I'm being annoying, but I just can't help it - I hate separating prototypes from functions. Yes, despite the fact that it's the conventional way. Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes! I don't know about you, but in my opinion, it looks ugly.

I know that most of you on this board strongly supports that we should follow the conventions at all costs. But I strongly believe that I do have a point. It's just my opinion. Please don't hate me for it. It's not my intention to make enemies on this message board.

Thank you all for your help.

I prefer to include small file like stdio.h and be able to compile my project using printf, scanf etc, when to include code for these functions in my own code

[dwks]

Doesn't solve my problem. I'd still have to separate prototypes from implementations. Sorry, but my point still stands. I apologize if I'm being annoying, but I just can't help it - I hate separating prototypes from functions. Yes, despite the fact that it's the conventional way. Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes! I don't know about you, but in my opinion, it looks ugly.

I know that most of you on this board strongly supports that we should follow the conventions at all costs. But I strongly believe that I do have a point. It's just my opinion. Please don't hate me for it. It's not my intention to make enemies on this message board.

Thank you all for your help.

Create a program that generates header files for you. It's simple enough and I'm sure it's been done before -- for c programs you could use cproto, but I don't think cproto works with C++ templates.

Or you could lump together some prototypes from different files into one header file. (Maybe that's not such a good idea either.)

[ChaosEngine]

Doesn't solve my problem. I'd still have to separate prototypes from implementations. Sorry, but my point still stands. I apologize if I'm being annoying, but I just can't help it - I hate separating prototypes from functions. Yes, despite the fact that it's the conventional way. Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes! I don't know about you, but in my opinion, it looks ugly.

at the risk of being harsh, tough! This is not a "convention", it is correct usage. If you don't like it, use another language. C/C++ are pretty much the only languages I know that enforce this kind of separation.

Think of it like this. It is a "convention" to drive with your hands at the "ten to two" position on the steering wheel, but if you don't, you'll probably still get by. However, it's more than a convention to drive on the correct side of the road (depending on your country). You may think that driving on the left is ugly, but if you end up in Ireland/NZ/Australia/UK you have no choice. You may even get away with it on a small empty road but as soon as you hit a city or a motorway.... CRASH!

I know that most of you on this board strongly supports that we should follow the conventions at all costs. But I strongly believe that I do have a point. It's just my opinion. Please don't hate me for it. It's not my intention to make enemies on this message board.

Thank you all for your help.

Unfortunately, there's a difference between opinion (i.e. manutd belief that templates don't require an entire book) and error. You can have all the opinions you want, but it doesn't change the fact that you are wrong in this case.

We don't hate you for it. We're simply trying to educate you. If you persist with this incorrect approach, it will bite you, but I don't have to worry about that. Besides, I just can't bring myself to hate someone over a programming language! (skiing vs. snowboarding, road vs mountain biking, aikido vs judo, these are subjects worthy of hatred! )

[anon]

Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes!

You don't need 7 extra files. If all the functions belong logically together (or even if not, if you prefer being lazy), you can put all the prototypes in one header and include it in all 7 implementation files.

I often have one header per class, but the methods are distributed among several files (grouped by similar functionality). I dislike source files longer than 100 lines ... coming from a version of BASIC where the entire source must be in one file.

Create a program that generates header files for you.

Wow, although I'm considering using some sort of flow-charts or class-diagrams, writing headers is actually the place where I tend to do most of the thinking. Implementation files are just an annoyance where you do bug fixing.

Also, consider using some IDE, that keeps all the files of a project nicely together and tells the compiler what to do with these for you.