Sign in to follow this  
sipickles

Central hub or individual including...

Recommended Posts

sipickles    240
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

Share this post


Link to post
Share on other sites
rip-off    10976
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".

Share this post


Link to post
Share on other sites
Omid Ghavami    1007
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.

Share this post


Link to post
Share on other sites
rip-off    10976
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.

Share this post


Link to post
Share on other sites
Omid Ghavami    1007
Quote:
Original post by rip-off
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.


Ah, that's good to know, thanks for clearing that up! [smile]

Share this post


Link to post
Share on other sites
Antheus    2409
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.

Share this post


Link to post
Share on other sites
Omid Ghavami    1007
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this