organizing code files in C & C++

http://www.gamedev.net/reference/programming/features/orgfiles/page2.asp

 

通过四个pitfall讲解头文件的由来和好处，以及使用头文件定义inline func and template.

Remember that, as far as the compiler is concerned, there is absolutely no difference between a header file and a source file.

 

The key idea is that headers contain the interface, and the source files contain the actual implementation.This means that one source file uses another source file via the second source file's header.

 

main body

By now you're probably convinced that there are benefits to splitting up your project into several smaller files. So, how would you go about it? Although some of the decisions you make will be reasonably arbitrary, there are some basic rules that you should follow to ensure that it all works.

Firstly, look at how you would split your code into sections. Often this is by splitting it into separate subsystems, or 'modules', such as sound, music, graphics, file handling, etc. Create new files with meaningful filenames so that you know at a glance what kind of code is in them. Then move all the code that belongs to that module into that file. Sometimes you don't have clear module - some would say this should send out warnings about the quality of your design! There may still be other criteria you use for splitting up code, such as the structures it operates upon. (Often "general purpose" functions can be split into string-handling and number-handling, for example.) And occasionally a module could be split into two or more files, because it might make sense to do so on logical grounds.

Once you have split it up in this way into separate source files, the next stage is to consider what will go into the header files. On a very simple level, code that you usually put at the top of the source file is a prime candidate for moving into a separate header file. This is presumably why they got termed 'header' files, after all.

This code to go in a header usually includes some or all of the following:

• class and struct definitions
• typedefs
• function prototypes
• global variables (but see below)
• constants
• #defined macros
• #pragma directives

(Additionally, when using C++, templates and inline functions usually need to be in the header file. The reasons for this should become clear later.)

 

...

Conclusion

If done properly, organizing your files this way can speed your development without hindering you at all or introducing any extra problems. Although it seems like there is a lot to consider when doing so, it becomes second nature in no time. Just remember these key points:

• Split your code up along logical module divisions
• The the interface into the header files and the implementation in the source files
• Use forward declarations wherever possible to reduce dependencies
• Add an inclusion guard to every header file you make
• Don't put code in the headers that might adversely affect source files that include it

Good luck!