Source file inclusion

I've been reading through a lot of the threads here, and one point of confusion that seems to be a re-occurring theme for newer programmers is how to properly include files.

To be honest, I don't know if I do it properly either, so hopefully this will totally clear this matter up.

I've been doing this all using Dev-Cpp.

NOTE: One point I'd like to make, is that there is a BIG DIFFERENCE in how the compiler/linker behaves depending on if you're creating a PROJECT or not.




The PROPER way, and please correct me if I'm wrong, to include source files is as follows:




1) CREATE A NEW PROJECT (whatever type it may be)

2) SEPARATE THINGS MODULARLY (this should be a given)(i.e. don't put 2 different class declarations in the same file, don't put implementations of different classes in the same file, etc.)

3) USE INCLUSION GUARDS ON HEADER FILES:

Code:

---

#ifndef __MYCLASS_H
#define __MYCLASS_H

class MyClass
{
    /*  Your Class Declaration Here  */
};

#endif

---

4) If you're creating a PROJECT, the LINKER will automatically scan for the definition files of a header file. Example:

We have a project with the following files:

main.cpp, MyClass.h, MyClass.cpp

WE INCLUDE LIKE THIS:

main.cpp -needs only to include "MyClass.h"

MyClass.h -doesn't need to include ANYTHING

MyClass.cpp -needs only to include "MyClass.h"




NOTE: If you're not creating a project, the above WILL NOT WORK!!! In this situation, I believe it's impossible to avoid including the source file (.cpp files). So I usually "include" the source file at the bottom of the header file, that way main still only needs the header file.



If anyone has anything to add, or if there are any corrections for this, please post them, not only for others' benefit, but for mine as well!


One question I do have however, is if you have a non-class declaration header file (just functions) should any external dependencies be included in the HEADER or SOURCE file?

For example:

If I have the files: -functions.h and -functions.cpp
and these functions require <iostream> and I'd like to use cout and cin, does the following:

Code:

---

#include <iostream>
using std::cout;
using std::cin;

---

go in the HEADER or SOURCE? I've always placed them in the SOURCE file, it just seems to go with convention.



If anyone has anything to add, or to correct, please do so, for my benefit and for the benefit of others, Thank You!

Well, an IDE can have a concept of project, but that doesn't mean that a non-IDE solution can't compile multiple files:
g++ -Wall xx.cpp ..\shared\yy.cpp -I..\shared -o xx.exe

This combines the "shared" (class definition and implementation) in yy.h and yy.cpp into teh xx.cpp "main" program. This is actually a copy directly from my command-prompt window on my work-machine, but I've replaced the actual names of the files involved.

--
Mats

Also, whilst it's recommended to have only one class in a pair of .h & .cpp files, you can certainly have cases where a tight coupling between two classes can make a good case for having both in the same file, particularly if the overall size of both is failry small. Say for example you read some sort of record from a file, which is then combined into a larger object, and the relationship between the small object and the larger one is a fixed relationship, then it makes sense to have both in the same file-pair.

--
Mats

Quote:

---

Originally Posted by matsp

Well, an IDE can have a concept of project, but that doesn't mean that a non-IDE solution can't compile multiple files:
g++ -Wall xx.cpp ..\shared\yy.cpp -I..\shared -o xx.exe

---

I knew I should have mentioned object files! I just figured most people (especially beginners) are using an IDE of some sort.

Most of us who venture into the dark world of the command-line however know this already.

...and a discussion in makefiles is probably too off topic for this forum!

Ok, so I'm objecting against this:

Quote:

---

NOTE: If you're not creating a project, the above WILL NOT WORK!!! In this situation, I believe it's impossible to avoid including the source file (.cpp files). So I usually "include" the source file at the bottom of the header file, that way main still only needs the header file.

---

Either tell people that they need to be woring in a project if they split the project into more than one source file - or tell them how it is done with command-line and makefiles. This above text is just plain leading to bad stuff - including .cpp files is not recommended under any normal circumstances.

--
Mats

On to your question:

Code:

---

One question I do have however, is if you have a non-class declaration header file (just functions) should any external dependencies be included in the HEADER or SOURCE file?

For example:

If I have the files: -functions.h and -functions.cpp
and these functions require <iostream> and I'd like to use cout and cin, does the following:
Code:

#include <iostream>
using std::cout;
using std::cin;

go in the HEADER or SOURCE? I've always placed them in the SOURCE file, it just seems to go with convention.

---

This should, generally go in the .cpp file. However, you may find that you use this so often that it makes sense to have a specific include file that does some common functions and include files that are used "everywhere".

--
Mats

Quote:

---

Originally Posted by matsp

Ok, so I'm objecting against this:

Either tell people that they need to be woring in a project if they split the project into more than one source file - or tell them how it is done with command-line and makefiles. This above text is just plain leading to bad stuff - including .cpp files is not recommended under any normal circumstances.

--
Mats

---

I don't mean to lead people down the wrong path... srry!

I said that only because in school, this is how things had to be done. Not because our teachers were bad, but they wanted to avoid confusion, didn't want the grad students checking the programs having to follow special compilation instructions, etc.

What they wanted was to open up "main", click compile & run, and be on their merry way.

I did feel the point of what I wrote was to make a project, I added the bit about the non-project stuff so people can see the difference. I agree with you 100% matsp, but some people, including me, don't like to be told to do something without understanding why, and seeing what the wrong way of doing something is.

By the way, your inclusion guard names are not recommended. Names beginning with an underscore followed by an uppercase letter, or with two underscores, are reserved to the implementation for any use. __MYCLASS_H is reserved to the implementation for any use on both counts.

I might suggest as possible alternatives:
MYCLASS_H
GUARD_MYCLASS_H
MYCLASS_H_