TITLE: const objects in include files

PROBLEM: abed@saturn.wustl.edu, 2 Jul 92

 I noticed that the size of my programs
 (executables, and not the code itself) went up considerably as compared
 to C. I think it has to do with the fact that I have a main header file
 called Clib.h that I include in all my routines and programs which in
 turns (i.e the Clib.h) includes all the include files that I need, like
 ostream.h, math.h, matrix.h, complex.h.....etc.
 
 Now what I don't understand is: is the number of header files that you
 include increase the size of the executables ? I thought header files
 are only used during the compilation stage ?. I do have a complex class
 and a couple of other classes that have a large number of inline
 functions. Is that making my program size explode.
 
 [Example of hello world program that went from 90k to 163k by including 
 his header omitted]



RESPONSE: nikki@trmphrst.demon.co.uk (Nikki Locke)

The most likely explanation is that you have some const objects declared 
in your header. It is a feature of C++ that ...

const int i = 100;

actually creates a static object in every object file whose source file
includes the header. This is bad enough for the built-in types, but it
suddenly becomes much worse for user-defined types ... 

const MyClass myObject(100);

Will not only reserve storage for myObject in all the object files whose
source files include the header, but (assuming MyClass has a constructor)
will also mean that such object file must be linked with the object
file(s) that contain the constructor, the destructor, and all the virtual
functions. 

And it gets even worse if you have inline constructors, destructors
and/or virtual functions. The actual code for these will all be generated
in EVERY object file whose source file includes the header.

Of course, templates can make the situation worse again !



So, in summary ...

It is a bad idea to include unnecessary header files anyway, because
changing the header forces you to recompile every source file in your
project. [Whoever implemented Borland's precompiled headers please take 
note :-]

Avoid having lots of (static) const objects. Remember, static is the
default - you have to explicitly state "extern" to get only a single copy.
[* See below]

It is a bad idea to use inline constructors and destructors, because they 
generate lots of code (have a look at the assembler output for a 
constructor one day), doubly so where virtual base classes are involved.

It is not often helpful to have inline virtual functions, either !

Of course, there are exceptions to these rules of thumb - but make sure
you know why you are breaking them, and the cost/benefit of doing so.



[*] I think the advice given in many C++ books to use ...

const int arraySize = 100;
char array[arraySize+1];

instead of ...

#define ARRAYSIZE 100
char array[ARRAYSIZE+1];

is not terribly helpful. I prefer the (rather nastier looking at first 
sight, I admit) ...

enum { arraySize = 100 };
char array[arraySize+1];

This saves sizeof(int) bytes in each object that includes this header. It 
prevents unpleasant things like ...

void confuseTheProgrammer(const int *zap)
{
	*(int*)zap = 200;
}

and it has the same name space advantages of the const version.

Note that I suggest this only for constants that are used to size arrays -
other constants can often be made extern.