Curiosity: including .cpp files

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:

Code:

---

#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

Code:

---

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

using namespace std;

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

---

helloworld.cpp code

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.

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

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.

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?

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 )

Quote:

---

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

---

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

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

Quote:

---

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

---

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:

Code:

---

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

Code:

---

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

Quote:

---

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.

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

Quote:

---

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

---

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.

Quote:

---

Originally Posted by Mr_Miguel

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

Quote:

---

Originally Posted by Mr_Miguel

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

Quote:

---

Originally Posted by Mr_Miguel

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!

Quote:

---

Originally Posted by Mr_Miguel

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! :D )

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by ChaosEngine

(i.e. manutd belief that templates don't require an entire book)

---

Hehe :)

Quote:

---

Originally Posted by Mr_Miguel

I'd still have to separate prototypes from implementations.

---

Believe it or not, that's a good thing. It's a place where all function headers are grouped together, so if I need to look up how to call a function, I can do it there. With no source code to get in my way. (I use Java a lot. I know from experience how annoying source code is.)
And don't tell me to use a reference for that. Typically, this is my own code, and it doesn't have any reference beyond well-commented code.

Quote:

---

I hate separating prototypes from functions.

---

You better learn appreciating it.

Quote:

---

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 have written projects that had 30 headers or more, for that many source files. And I consider those projects small to medium-sized. I think it looks neat.

@ChaosEngine:

My approach isn't necessarily wrong. It works as long as I keep track of function duplicates. Driving on the wrong side of the road is way dangerous than driving on the right one (I do have a driver's license, by the way), but doing this the way I did isn't necessarily dangerous. Then again, it may bite me like you said, but I guess I'll have to find out for myself. When something feels right to me, I can't just take it out of my head.

@CornedBee:

If you ask me, the reason why I like my approach better is because I learned Java before I got myself into C++. However, I strongly prefer C++ to Java, many reasons involved in my preference which I shall not disclose. Learning Java before C++ might be behind the reason why I like grouping source code with prototypes. And besides, I always keep prototypes at the top, so it isn't a problem at all if I need some kind of reference. You also said you THINK it looks neat with all of those 30 headers of yours. The keyword here is THINK. It is a matter of opinion once again.

@All who participated in this topic:

There is no need for further posts. I asked a question, you gave me your answers. I got your points, despite the fact that I don't exactly feel the same way. I say it again: if I have to pay the price of separating prototypes from implementations, so be it. At least now I know why people tell beginners and the like that they should only include header files, which means something good came out of all of this. Thank you all for your participation. Over and out.

Quote:

---

I got your points, despite the fact that I don't exactly feel the same way.

---

Then I declare jihaad against you. You must die.

Quote:

---

Originally Posted by 7stud

Then I declare jihaad against you. You must die.

---

ROFL!!! :cool:

Quote:

---

Originally Posted by Mr_Miguel

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.

---

Some of my projects have well over 50 .cpp and 50 .h files ;) I usually put no more than one major class per .h/.cpp file (I'll put helper classes that are used only in conjunction with the main class, though).

It actually really helps readability in my opinion. If I want to know the interface of my class, I can look at the .h and see everything very quickly; if I am want to look at implementation, I have the .cpp.

Most of the time when I code I have one .cpp file open and many .h files, as I am coding one section and referring back to the public interfaces of my other classes.

Breaking apart the interface and implementation can actually give a very large compile-time boost, too, especially on large projects. A change to a .CPP file (implementation) typically means only that .cpp needs to be recompiled, where a change in the .h means everything that includes that header must be recompiled.