all.h

Discussion in 'C Programming' started by atindrasrs@gmail.com, Mar 9, 2008.

  1. Guest

    suppose my source code is divided into several modules and there are
    many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    dependencies. In such a case, is it better to have a single header
    file "all.h" like this -

    all.h

    #include "a.h"
    #include "b.h"
    #include "c.h"
    #include "d.h"


    Then include this all.h in all the .c files ??
     
    , Mar 9, 2008
    #1
    1. Advertising

  2. On Sun, 09 Mar 2008 00:01:45 -0800, atindrasrs wrote:
    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header file
    > "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    >
    > Then include this all.h in all the .c files ??


    That depends. This way will save you on typing initially, but when you
    want to add #include "e.h" to all.h, you have to check all of a.c, b.c,
    c.c, and d.c, to make sure it doesn't conflict with any of them. And if it
    does conflict, you can't just leave it out, you have to update the .c
    files. If you think this might be a problem, use the more explicit
    version. If you don't, pick whichever you like best.
     
    Harald van Dijk, Mar 9, 2008
    #2
    1. Advertising

  3. santosh Guest

    wrote:

    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header
    > file "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    >
    > Then include this all.h in all the .c files ??


    This method won't scale well to large projects. If you eventually end up
    with dozens of headers, compilation time is going to come down to a
    crawl.

    Include in each .c file only the headers that it needs. This is the best
    way from long term maintenance POV and also makes you think and review
    things at each modification.

    The "include all headers" method is okay for small or perhaps medium
    sized projects, but will get out of hand for large ones.

    For example, can you imagine each .c file in the Linux kernel or in gcc
    or in glibc including every header in the source base? Think of the
    mess.
     
    santosh, Mar 9, 2008
    #3
  4. Ian Collins Guest

    wrote:
    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header
    > file "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    >
    > Then include this all.h in all the .c files ??


    There is a possible benefit if your tools support precompiled headers.
    Otherwise you will create too much coupling, changes to a header x that
    is not used by source file y causing y to be recompiled.

    A compromise if your tools support precompiled headers is to group
    together a subset of commonly used headers in one file to improve
    compile times.

    --
    Ian Collins.
     
    Ian Collins, Mar 9, 2008
    #4
  5. CBFalconer Guest

    wrote:
    >
    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header
    > file "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    > Then include this all.h in all the .c files ??


    I believe not. I consider the best means is to provide one .h file
    to go with each .c file, specifying the access to that code
    allowed. You can also have some specialized .h files to establish
    some constants, etc.

    Now you can arrange to only include the necessary areas in each .c
    file (including its own .h file). Note that this way each .c file
    indicates what other files affect it.

    You still have the option of building some big subsets by writing a
    ..h file that simply specifies:

    #include a.h
    #include b.h
    #include c.h
    ... etc ...

    but that is only for your convenience.
    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Mar 9, 2008
    #5
  6. On Sun, 09 Mar 2008 00:01:45 -0800, atindrasrs wrote:

    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header file
    > "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    >
    > Then include this all.h in all the .c files ??


    Don't be lazy, just type the includes. It's not that big a deal. Plus
    it'll help you keep a handle on circular dependencies and similar things
    that are generally bad.
     
    Scott S. McCoy, Mar 9, 2008
    #6
  7. Ed Prochak Guest

    On Mar 9, 8:01 am, wrote:
    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header
    > file "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    > Then include this all.h in all the .c files ??


    NOoooo! It is not better.

    Just consider two modules, A and C that happen to define functions of
    the same name, foo(), or macros of the same name, or any other
    possible collisions.

    When such collisions happen, it is not pretty because it does not
    always cause a compile error. IOW, it blows up at runtime. Not fun. So
    NO not good practice.

    Ed
     
    Ed Prochak, Mar 9, 2008
    #7
  8. Ian Collins Guest

    Ed Prochak wrote:
    > On Mar 9, 8:01 am, wrote:
    >> suppose my source code is divided into several modules and there are
    >> many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    >> file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    >> dependencies. In such a case, is it better to have a single header
    >> file "all.h" like this -
    >>
    >> all.h
    >>
    >> #include "a.h"
    >> #include "b.h"
    >> #include "c.h"
    >> #include "d.h"
    >>
    >> Then include this all.h in all the .c files ??

    >
    > NOoooo! It is not better.
    >
    > Just consider two modules, A and C that happen to define functions of
    > the same name, foo(), or macros of the same name, or any other
    > possible collisions.
    >
    > When such collisions happen, it is not pretty because it does not
    > always cause a compile error.


    It should.

    --
    Ian Collins.
     
    Ian Collins, Mar 9, 2008
    #8
  9. GMM50 Guest

    On Mar 9, 2:01 am, wrote:
    > suppose my source code is divided into several modules and there are
    > many header files like a.h, b.h, c.h, d.h. It is possible that one .c
    > file say d.c needs b.h and c.h, c.c may need a.h and so on. lot of
    > dependencies. In such a case, is it better to have a single header
    > file "all.h" like this -
    >
    > all.h
    >
    > #include "a.h"
    > #include "b.h"
    > #include "c.h"
    > #include "d.h"
    >
    > Then include this all.h in all the .c files ??


    If you're going to have a large complicated project then I've found it
    best to keep separate c and h files. Why did you divide your code
    into several c files. Probably to keep it organized better. So that
    seems to indicate you'll be better served with separate h files.

    Let's say your project is up and running, time has passed so you not
    so close to your code and you need to make a small change. I thinks
    it's better to keep that change isolated to individual modules say a.c
    and a.h.

    Even if you have to make a large change. Say you can't purchase a
    component that is part of your system and need to change to another
    with different interface characteristics. Again separate modules
    would seem to me to be better.

    If you have a simple project then perhaps one c file and no h files
    would be better.

    my 2 cents.

    george
     
    GMM50, Mar 9, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrzej Wegrzyn
    Replies:
    2
    Views:
    752
    John Saunders
    Aug 18, 2003
  2. vivek
    Replies:
    2
    Views:
    6,294
    pushp
    Jun 14, 2007
  3. Al Hatch
    Replies:
    3
    Views:
    1,019
    Johannes Koch
    Jun 5, 2006
  4. Moderator
    Replies:
    0
    Views:
    334
    Moderator
    Aug 7, 2006
  5. PokerMan
    Replies:
    3
    Views:
    345
    Mark Rae
    Apr 9, 2007
Loading...

Share This Page