Thread: quick question about header files

so i've got this class called room that i'm testing on its own. i've got 3 files, room.h, room.cpp which has the definitions, and then i have the driver program to test the class:

Code:

// room.h //
#include <iostream>
using namespace std;

class room
{
public:
    void showRoom() const;      // displays the current room
    room();                                // default constructor
    ~room();                             // default destructor

private:
    string description;
    int status;
};

Code:

// room.cpp //

#include <string>
#include "room.h"

void room::showRoom() const
{
    system("cls");
    cout << description;
}

room::room()
{
    description = "There is no description of this room.";
    status = 0;
}

room::~room()
{
}

Code:

// room driver.cpp //

#include "room.h"

int main()
{
    room emptyRoom;

    emptyRoom.showRoom();

    cin.get();
    return 0;
}

thats my code so far. it works and everything, i'm just wondering what's the best way to make use of the header file? i mean, if there are benefits to putting all the includes in the header, or if it's better to keep them separate and declare them for each .cpp file... i think you know what i'm getting at. just curious if there's a generally used standard or if it's all up to personal preference. thanks

The way you have it setup is fine except for the standard header includes. In each file you should include all of the standard headers you need, and none you don't.

So in room.h, you use string, so you should include <string>. You don't use anything from <iostream>, so you should not include <iostream>.

In room.cpp, you use "room.h", both <string> and <iostream>, as well as <cstdlib> (for system), so you should include all four.

In main.cpp, you use "room.h" and <iostream>, so you should include both.

BTW, "none you don't" does not aply to <cstdlib> even though your program compiles without it. You should include it because that is the appropriate header for the system function, and if you try to compile your program without that include on another platform it might not work.

I would also encourage you to look at inclusion guards when writing your header files.

thanks guys, that definitely answers my question, and hey, Daved even answered my question about the cstdlib include file, even though I didn't even ask it. I was thinking about asking it, but decided not to.
and as a matter of fact (what a coincidence) earlier i was looking a little bit about inclusion gards, but i figured i'd read about that a little later. what i want to know is this: do you have to name the #IFNDEF __ROOM_H__ the same as the room.h file for example? i mean, can you have that #IFNDEF named something else, and still accomplish the same thing? does it need to have the two underscores before and after the name? i guess i just need to know the proper syntax for that stuff. it doesn't seem to explain that much detail in my old C book, and my new book on C++ doesn't even talk about preprocessor directives; apparently that's not considered beginner material. i'd appreciate a quick tutorial on the rules of those inclusion gards, or a link to a tutorial, whichever. thanks

oh, and about the first thing, including all the necessary files in each header or .cpp file, what about having the "using namespace std;" in the header file? should i apply the same rules to the using command as well as the #include command?

A lot of ways are preference, but some have their faults. As already said, include a header in the file if you need anything from that header (string, room class, cout/cin, etc.), mostly for the reason that it makes it clear which header things are coming from. Some would make 1 .h file that includes all the header files, then just include that header file in all .cpp files; however that would make it hard to tell where functions/classes/etc come from for the programmer and viewer. Also when using a Project, if you change an included file, and not the file part of the Project, then when compiling the Project the compiler sees no change and uses the old .o (object) file, which is why you should at the least always have as many of your .cpp files part of your Project list (or makefile); for example have the main .cpp include say room.h which includes room.cpp (not part of Project), which obviously results in problems.

Originally Posted by elad

I would also encourage you to look at inclusion guards when writing your header files.

#ifndef FILENAMEHERE_H_, and #define FILENAMEHERE_H_ at the beginning, and #endif at the end, of the file. Just to clarify for incase other viewers dont know.

i don't quite understand what you said about including files and whether or not they are part of the project. and i never did include room.cpp anywhere. FROM main i included room.h, and from room.cpp i included room.h and it works fine. that's how i was taught in class... but the three files are part of the project, and both main.cpp and room.cpp are compiled everytime i do the rebuild. i know not to reuse the .o files if i make a change.

Oh, yeah it doesnt apply in your case. I forgot your name too, linux, you probably use makefiles then and not like Dev-Cpp which WILL use old .o files, causing the problem described above if you did include a .cpp file, as some prefer to do.

ok, i see where it could be a problem having the using directive in header files. i'll stop doing that from now on. and i might start to do the "using std::cout;" stuff in the .cpp files. just in case.
and the inclusion gards make a lot more sense now, though i have one more question about it. is it correct that if i have for example a project with 2 .cpp files and one .h file, that if BOTH .cpp files include that same .h header, and there are no inclusion gards, the .h file is compiled twice (or could potentially be compiled twice)? i know that in dev-cpp it works fine without inclusion gards, at least with that example.

I know Dev-Cpp hasnt always protected me from those problems, they result in linker errors, because there is two copies of the variables/etc from the .h file.

ok, thanks guys. i think i get it now.