Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Blew

#includes in header files

This topic is 5365 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A teacher at my university says out loud that you should NEVER #include on header files. Only the implementation files have includes. I can understand that this is a style that he choose. I just don''t get it is why he teaches this as it''s some sort of crime not doing it. Another ''style'' that i have learned (and is the one i use) is that each file, .h or .cpp, should #include whatever it needs. I''m sure these aren''t just ''styles'' and there must be reasons to use one or the other. Can anyone enumerate them? Thanks.

Share this post


Link to post
Share on other sites
Advertisement
I include everything I need in a .h or .cpp file...

Not including anything in a header file *might* be more clear.. but doesn''t it limit a lot the possibilities of your class?

Share this post


Link to post
Share on other sites
I guess the two other "styles" would be...

1: it's okay to #include external library files in a .h file (like gl.h, windows.h, stdlib.h, etc), but you never #include your own .h files within a .h file. If you need to reference one of your own classes in a .h file, then you predeclare it by just saying "Class MyClass;" or "Struct MyStruct;", and then any functions that need to actually use MyClass can't be defined in the .h file, they have to be defined in the .cpp file.

2: you go nuts and #include whereever you want to. On big projects, this style usually leads to problems with circular dependancies, which you will have to solve on a case-by-case basis.

EDIT: you could also have a style 3: you set up a hierarchy of classes, and classes can only #include .h files of classes that are "lower" on the hierarchy. At the bottom of the hierarchy, you have the simple classes like Image, Vertex, Matrix, String, and at the top of the hierarchy, you have the classes that use lots of other classes, like GameEngine, WorldView, AI. This will avoid problems of circular dependancies.

I think the best way is using style 1. It doesn't take that much more effort to stop yourself from #including your .h files within .h files, and it's a reliable way to avoid circular dependancies.

Style 3 will work fine, but I think it's too much effort spent to figure out what the file hierarchy will be. Also, the hierarchy might change a lot, you might one day decide that the Matrix should have a function that returns a Vertex, so then Matrix needs to be higher up on the hierarchy than Vertex. If you just stick to style 1 from the get-go, you will avoid all of these headaches.

[edited by - pinacolada on March 6, 2004 7:02:52 PM]

Share this post


Link to post
Share on other sites
If you put headers in other headers, when you make changes to those headers, you''ll ending up recompiling source you didn''t have to.

It''s not so bad on a small project, but do you know how much it sucks to go through a 10 minute recompile if you want to add a single member to a class? On larger projects, compile times can be in 10''s of hours. Throwing headers where ever you want on these types of projects would totally cripple you.

I agree with your teacher.

Share this post


Link to post
Share on other sites
With C++ files and stuff, a good style is to give each object its own .h header file, and each object is found in it''s own .cpp file. Your professor is trying to establish a good style is all, for the duration of the class, use it.

As for potential issues with including header files inside of header files, its mainly one of organization. For instance, say I had a particular program where every object has some kind of legitamate reason to interact with another. Rather than a really long list of #include''s that are in each file, I could have one header file, call is mystdinc.h, and it will have that list of includes, and then every .c file I write, they just #include "mystdinc.h" and I save some space. This is rather lazy method of doing it, and I don''t suggest it, but for the most part, all #include does is copy+paste from one file into another.

As for circular dependancy, with objects you don''t neccessarily have this problem, since the variables have to be instantiated first. Just do the header definition thing.
#ifndef MY_HEADER_H
#define MY_HEADER_H
/* stuff */
#endif

Thats a fairly common and good practice that protects from double definition.

Now, the last issue to worry about is global variables. In the .c file you''d have a global variable, int total_coins;, and in the header, extern int total_coins;. Extern and define the variable and you have a compiler error. As far as I can tell, no standard practice has shown up that protects this. Two popular methods are as so:
1) Don''t extern variables in headers, extern them where they are needed in the .c files.
2) Go through a complex method of #if''s and #defines to guard against including the extern definition if the actual definition is upcoming.
#define MY_GAMEINFO_PROTECT
#include "mystdinc"
int total_coins;

---
#ifndef MY_GAMEINFO_PROTECT
extern int total_coins;
#endif


If this sorta stuff confuses you too much, stick to c++ and your professor''s style demands.

Share this post


Link to post
Share on other sites
No, it doesn''t confuse me. That has been my practice for some years now. I just wanted to know why that teacher is so strict about that.

I find it very annoying when someone, while teaching something, only say DO THIS instead of giving the reasons which make that a good practice.

BTW, he''s not even my teacher. He was some years ago. No i''m almost finished at the university and i''ll start to work soon. :D

Share this post


Link to post
Share on other sites
I put all my needed include files into one .h file and turn that into a precompiled header. This works perfectly for me.

Scott Simontis
e-mail:ageofscott@NOSPAM.comcast.net
AIM:ssimontis

Share this post


Link to post
Share on other sites
I tend to agree with your teacher except for heavy dependency between two classes.

For example, if I have CMP3 and I have CMP3System, I tend to put CMP3.h in CMP3System.h just because they rely so heavily on eachother anyways.

Doing it too often though, imo, creates very sloppy code.

Share this post


Link to post
Share on other sites
I definitely always include all the headers files that I need and only the header files that I need for that individual file. The exception is the precompiled header file.

The reason to include all the files needed in a header file is so that a file including that header doesn''t have to know what other files are needed and doesn''t have to worry about including files it doesn''t want to know about. In other words - every header file is "self-sufficient".

Never including header files in other header files will result in lots of problems due to the header files not being included in the right order. That is a real pain, especially if you have a big system and are including many files. If a header file is self-sufficient, it doesn''t matter what order it is included in.

The reason to include only the header files needed is to reduce dependencies. That will reduce compile time and help eliminate circular dependencies.

In order to reduce dependencies, I use forward declarations instead of including a header file whenever possible. Perhaps that is what the instructor is trying to promote.

Here is a very useful convention: in order to make sure that a header file is self-sufficient, I always make it the first #include in its implementation file.I always include the system header files last. Unfortunately, some system header files are broken because they are not self-sufficient and they have to be included first).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!