# Creating a large C Application

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

## Recommended Posts

About a year ago, I posted here saying I had been a sloppy programmer and I wanted to clean up my act, and I have, thanks to Linux. ;) Anyway, Im writing an app and its getting big... I want to know whats the best way to arrange header files. At the moment I just have 3: defines.h, structures.h and functions.h, but the functions.h file is requiring me to include lots more .h files, so I dont think this is a viable option. Should I create a seperate .h file for each .c file Ideas please...Whats the best way to arrange a large application, source-wise?

##### Share on other sites
A separate .h file for each C file is the normal way of doing it - except of course, for any C file which is entirely self-contained and doesn't export any functions or variables - usually this only applies to main() though.

Once it gets too awkward though you'll have to split it up into multiple directories, then get the .h separated from the .c files etc, and it will get icky.

How big is it anyway?

If there are less than 30 modules, putting them all in one directory sounds quite reasonable.

Mark

##### Share on other sites
yep, thats probably the way to go, but when theres multiple directories is it better to create a seperate "include" directory or put the .h files in with the .c files?

##### Share on other sites

http://www.gamedev.net/reference/articles/article1798.asp

It is always a good idea to keep stuff in different directories. I usually prefer a structure like this:

root
+--bin
+--doc
+--include
+--src

You should also try to separate your C functions by what they do. E.g. if you have some functions for network code, put them into network.c and declare them in network.h.

Also declare structs etc. in header files. Include only what is necessary.

##### Share on other sites
I stick to C++ so what I do may or may not be what you are looking for but in general I create a header file for each object I create. In C terms I would create a header file for each set of functions that are in the same catagory. The source files I create depend on how complicated the functions are. I like to be able to find a particular piece of code quickly so I tend to over organise for this.

If I have a class/set of functions that deals with something, lets say database access I will create a dbaccess.h header file that defines all the functions, but as there are likely to be some large functions I will break the source file into things like dbaccess_init.cpp, and dbaccess_shutdown.cpp, and dbaccess_read.cpp and so on.

Unless you're very short on diskspace there is no reason to clump everyhting into a couple files and to be honest I have had some very (VERY) strange compile time errors that I only caught because of how my source was divided up. One such error involved a bug in VC++ so you're not likely to run across it but you get my drift.

Edit: I always keep my .c/.cpp and .h files together. It's just easier for me but that doesn't mean it will be easier for you. But I also only keep my code in two directories. If it is application specific I keep it in the applications source directory if it is something I am writing that is reusable I keep it in a library directory with all my other code I have written for this purpose.

##### Share on other sites
It'd be a good idea to separate your public and private intefaces too, so you have a 'concrete' public interface in one .h file, and the inner system stuff in the private file. This helps to make sure your code is nicely black boxed and tidy.

##### Share on other sites
Quote:
 Original post by evolutionalIt'd be a good idea to separate your public and private intefaces too, so you have a 'concrete' public interface in one .h file, and the inner system stuff in the private file. This helps to make sure your code is nicely black boxed and tidy.

That's a good idea, however for me most of my public interface functions are inline and are in the header files. But this goes along with what I was saying as well, if you can divide up your code do it. It makes everything much cleaner to work with.

##### Share on other sites
Quote:
 Original post by NodgerI want to know whats the best way to arrange header files. At the moment I just have 3: defines.h, structures.h and functions.h, but the functions.h file is requiring me to include lots more .h files, so I dont think this is a viable option. Should I create a seperate .h file for each .c fileIdeas please...Whats the best way to arrange a large application, source-wise?

The best way is to encapsulate similar ideas into coherent units. For example, suppose your software has four main components: graphics, sound, input, and the filesystem. You would probably create three different header files: graphics.h, sound.h, input.h, and filesystem.h and four different c files with the same names. Each of the header files would include the PUBLIC INTERFACE to the subsystems. You only need include declarations in your header files that other modules need to interact with the module. This is called information hiding and it will simplify your applications and help to make modules more portable. Any function prototypes, struct definitions, constants, etc. that will not be needed by other modules should be placed directly in the .c source file.

All structs, functions, and constants that are needed to interact with the modules should be included in that module's header file. There is no need to create separate "graphics_functions.h", "graphics_structures.h", and "graphics_defines.h" headers; You only need "graphics.h"

##### Share on other sites

A seperate directory fro bin,src and include. Very UNIX.

I don`t think theres any easy answer to my question. It depends on how systemdependant the project is I suppose.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 22
• 17
• 46