Central hub or individual including...
Author
Hi,
I have an application which had a central include file, hub.h
This held all the other include files for every part of the app.
Is this not inefficient? Every header holds EVERY other header?
What effect will that have - Code bloat, source bloat, slow compilation?
Have I wasted my time trying to link each section directly?
:P
Thanks
Simon
Yeah, that is a bad idea. However of all the problems you mentioned only slow compilation times are likely to occur. This problem will grow with the number of files in your project.
A more serious problem is lack of proper dependency control. By keeping includes local to the header and source file in question, it is much easier to see the dependencies which each class or module has.
And again you are using the word "link" (which has a very special meaning for a language like c++) where you should be using "include".
A more serious problem is lack of proper dependency control. By keeping includes local to the header and source file in question, it is much easier to see the dependencies which each class or module has.
And again you are using the word "link" (which has a very special meaning for a language like c++) where you should be using "include".
Quote:Original post by sipickles
Hi,
I have an application which had a central include file, hub.h
This held all the other include files for every part of the app.
Is this not inefficient? Every header holds EVERY other header?
What effect will that have - Code bloat, source bloat, slow compilation?
Have I wasted my time trying to link each section directly?
:P
Thanks
Simon
I can't really comment on the effects on compile time, although logically I would guess that if you have compile guards it shouldn't cause any such problems in the standard case. But I have a feeling there may be certain compile time issues, so I digress.
There are a few practical problems I can think of however. Let's say you want to re-use one of your classes in another project.
Quote:Original post by Omid Ghavami
I can't really comment on the effects on compile time, although logically I would guess that if you have compile guards it shouldn't cause any such problems in the standard case. But I have a feeling there may be certain compile time issues, so I digress.
There are a few practical problems I can think of however. Let's say you want to re-use one of your classes in another project.
Include guards don't help as the compiler will process all the headers for each translation unit. In fact having a central header file renders include guards pointless as no file (apart from the "main" header itself!) can be included twice.
Quote:Original post by rip-offQuote:Original post by Omid Ghavami
I can't really comment on the effects on compile time, although logically I would guess that if you have compile guards it shouldn't cause any such problems in the standard case. But I have a feeling there may be certain compile time issues, so I digress.
There are a few practical problems I can think of however. Let's say you want to re-use one of your classes in another project.
Include guards don't help as the compiler will process all the headers for each translation unit. In fact having a central header file renders include guards pointless as no file (apart from the "main" header itself!) can be included twice.
Ah, that's good to know, thanks for clearing that up! [smile]
Probably the best answer would be pre-compiled headers.
You define a single, application-wide header, that includes the headers that will not change (they are considered static).
Good candidates for this are system libraries, 3rd party libraries needed for entire application and a small selection of your own widely shared symbols or definitions.
Compiler will then process this header once, and reduce compilation times on subsequent runs.
The disadvantage is obviously that changing pre-compiled header will force your entire project to be recompiled, or, if not re-compiled properly, even lead to plenty of obscure errors.
You define a single, application-wide header, that includes the headers that will not change (they are considered static).
Good candidates for this are system libraries, 3rd party libraries needed for entire application and a small selection of your own widely shared symbols or definitions.
Compiler will then process this header once, and reduce compilation times on subsequent runs.
The disadvantage is obviously that changing pre-compiled header will force your entire project to be recompiled, or, if not re-compiled properly, even lead to plenty of obscure errors.
Quote:Original post by Antheus
Probably the best answer would be pre-compiled headers.
You define a single, application-wide header, that includes the headers that will not change (they are considered static).
Good candidates for this are system libraries, 3rd party libraries needed for entire application and a small selection of your own widely shared symbols or definitions.
Compiler will then process this header once, and reduce compilation times on subsequent runs.
The disadvantage is obviously that changing pre-compiled header will force your entire project to be recompiled, or, if not re-compiled properly, even lead to plenty of obscure errors.
But don't you usually just include the pre-compiled header to source files and not to header files? Perhaps I'm mistaken.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
