Proper #include sequence
-
I am working on a very large project and would like to know if their is a rule of thumb for the proper sequence for doing #includes. I have always put my #include's in headers and done no #includes in any of my .cpp files. When my projects get large and I use a lot of the same included files I put a master header and include it in every other header. For example: Utils.h
#include <io.h>
#include <pgmspace.h>
#include <delay.h>-Other helper functions that are
useful such as a custom printf()Display.h
#include "Utils.h"
#include "ctime.h"Display.cpp
#include Display.h
The reason I am asking is my target is VERY memory limited and I need to get things as small as possible so useless inclusions that and bulk I need to get rid of. My other method of doing things is to only include exactly what that .h/.cpp set requires and use a Globals.h with external decelerations for all cross file variables and definitions. I still do not understand how the linker pieces objects together when their are unused functions. I would imagine that the compiler runs through your code and only generates asm for the functions and variables you use. If their is a function that uses a 10x32bit array but your not using it the compiler skips it? Then in the linker stage if it notices their are duplicate functions in each of the objects it strips out the others and only includes one? If this is the case then my above question is just semantics and I should not worry and do what is easiest to maintain and cleanest.
-
I am working on a very large project and would like to know if their is a rule of thumb for the proper sequence for doing #includes. I have always put my #include's in headers and done no #includes in any of my .cpp files. When my projects get large and I use a lot of the same included files I put a master header and include it in every other header. For example: Utils.h
#include <io.h>
#include <pgmspace.h>
#include <delay.h>-Other helper functions that are
useful such as a custom printf()Display.h
#include "Utils.h"
#include "ctime.h"Display.cpp
#include Display.h
The reason I am asking is my target is VERY memory limited and I need to get things as small as possible so useless inclusions that and bulk I need to get rid of. My other method of doing things is to only include exactly what that .h/.cpp set requires and use a Globals.h with external decelerations for all cross file variables and definitions. I still do not understand how the linker pieces objects together when their are unused functions. I would imagine that the compiler runs through your code and only generates asm for the functions and variables you use. If their is a function that uses a 10x32bit array but your not using it the compiler skips it? Then in the linker stage if it notices their are duplicate functions in each of the objects it strips out the others and only includes one? If this is the case then my above question is just semantics and I should not worry and do what is easiest to maintain and cleanest.
-
I already use the #ifndef/#define inclusion guards. If you have a function in a say 'abs.h/abs.cpp' and include it in 'part1.cpp' and 'part2.cpp' and use it in each part upon compiling 'part1.o' and 'part2.o' will each have that function. When the linker combines 'part1.o & part2.o into final.exe' will the function still be included twice or does it weed out duplicates and just point them all to one?
-
I am working on a very large project and would like to know if their is a rule of thumb for the proper sequence for doing #includes. I have always put my #include's in headers and done no #includes in any of my .cpp files. When my projects get large and I use a lot of the same included files I put a master header and include it in every other header. For example: Utils.h
#include <io.h>
#include <pgmspace.h>
#include <delay.h>-Other helper functions that are
useful such as a custom printf()Display.h
#include "Utils.h"
#include "ctime.h"Display.cpp
#include Display.h
The reason I am asking is my target is VERY memory limited and I need to get things as small as possible so useless inclusions that and bulk I need to get rid of. My other method of doing things is to only include exactly what that .h/.cpp set requires and use a Globals.h with external decelerations for all cross file variables and definitions. I still do not understand how the linker pieces objects together when their are unused functions. I would imagine that the compiler runs through your code and only generates asm for the functions and variables you use. If their is a function that uses a 10x32bit array but your not using it the compiler skips it? Then in the linker stage if it notices their are duplicate functions in each of the objects it strips out the others and only includes one? If this is the case then my above question is just semantics and I should not worry and do what is easiest to maintain and cleanest.
You're actually doing things a bit backwards - in C and C++ the general rule is to only include the minimum number of other files in headers. You only want declarations included that are actually going to be used by clients of that header. While C isn't as bad as C++ I've seen large (250kloc) projects have their build times cut by a factor of 100 by using these techniques. It also avoids dependency fear - "aaarggghh, I can't change this header as absolutely everything includes it directly or indirectly and everything will build, bollocks, I'll just hack something in this C file to get 'round it..." Interestingly and generally (this depends on your compiler, most I use work this way) what you include doesn't usually have much effect on the code size. Declarations and macros don't occupy space in an object file - it's definitions that do. Exactly what the linker does depends on the linker (and how the compiler packages functions) but most modern linkers remove multiple definitions of objects with the same name. However some require command line switches to turn this on so it's a good idea to look at your compiler and linker docs and find out what all the switches do. One good rule to follow is that if your compiler is a C++ compiler it'll support multiple definition removal (saves the embarrassment of template explosion on code size), if it's just a C compiler then it may take some fiddling to do so. Cheers, Ash
-
You're actually doing things a bit backwards - in C and C++ the general rule is to only include the minimum number of other files in headers. You only want declarations included that are actually going to be used by clients of that header. While C isn't as bad as C++ I've seen large (250kloc) projects have their build times cut by a factor of 100 by using these techniques. It also avoids dependency fear - "aaarggghh, I can't change this header as absolutely everything includes it directly or indirectly and everything will build, bollocks, I'll just hack something in this C file to get 'round it..." Interestingly and generally (this depends on your compiler, most I use work this way) what you include doesn't usually have much effect on the code size. Declarations and macros don't occupy space in an object file - it's definitions that do. Exactly what the linker does depends on the linker (and how the compiler packages functions) but most modern linkers remove multiple definitions of objects with the same name. However some require command line switches to turn this on so it's a good idea to look at your compiler and linker docs and find out what all the switches do. One good rule to follow is that if your compiler is a C++ compiler it'll support multiple definition removal (saves the embarrassment of template explosion on code size), if it's just a C compiler then it may take some fiddling to do so. Cheers, Ash
I think I'm picking up what your throwing down now. For code size if you included every single c library header but didn't use a single function they provided the size of the code would not go up with every additional inclusion but because the compiler must do its job on every included file the compile time will increase will every include. So for my projects I should only include the minimum amount of headers for each file to keep things compiling as fast as possible and make maintenance easier. Originally my layout was:
// Uitls.h
#include <stdio.h>
#include <stdints.h>
#include <ctype.h>
#include <string.h>// Part1.cpp
#include "Utils.h"
// this file doesn't use ctype or strings
#include "ctime.h"// Part2.cpp
#include "Utils.h"
// this file doesn't use stdioAnd I should get in the habit of this way:
// Uitls.h
#include <stdints.h>// Part1.cpp
#include <stdio.h>
#include <stdints.h>
#include "Utils.h"
#include "ctime.h"// Part2.cpp
#include <stdints.h>
#include <ctype.h>
#include <string.h>
#include "Utils.h"