Re: Splitting a source code file

Discussion in 'C Programming' started by Gene, Jun 2, 2010.

  1. Gene

    Gene Guest

    On Jun 2, 12:00 pm, (Richard Harter) wrote:
    > My question of the moment is about splitting large source code
    > files.  For those who want to see real code an example may be
    > found athttp://home.tiac.net/~cri_a/san/source_code/projects/dfe_engine/dfe_e...
    >
    > (Warning: there is no internal documentation - if it was hard to
    > write, it should be hard to read. For the current discussion it
    > doesn't matter what's going on; however I will award five jelly
    > bean points and a gold star to anyone who wants to slog through
    > it.)
    >
    > This file has a simple superstructure with three parts.  The
    > first part consists of declarations, typedefs, etc.  The second
    > part defines public functions, i.e. functions that are visible
    > outside the file.  In the reference file they are an API.  The
    > third part defines private functions, i.e. functions not visible
    > outside the file.  They all are declared static.
    >
    > This is a very simple file structure, one that I find convenient.
    > It works nicely when a single file suffices.  What I would like
    > to do is split the file.  Part I goes into an include file.
    > Parts I and II (public and private) go into separate files.  The
    > issue is how to make the private functions in file II visible to
    > the public functions in file I.  
    >
    > One way to do this is to create a struct that holds pointers to
    > all of the private functions.  A more elaborate scheme declares
    > function pointer variables in the part I file and has behind the
    > scene code to copy the actual function pointers from the part II
    > file into the part I file.
    >
    > Incidentally, one reason for wanting to do the split is that I
    > want several "Part I" files that do different things.
    >
    > Any and all suggestions will be appreciated.
    >


    I know it's probably inconsequential in practice, but introducing a
    runtime overhead (e.g. cache burden for the function pointers) to
    support static structure is unsatisfying.

    I guess I'll ask the obvious question. Why not just #include
    "partIII.c" within partII.c ? It's a bit crufty, but in this manner,
    the static bodies are exposed for inlining even with a primitive
    compiler. The name space stays clean. You can avoide top-declaring
    prototypes for the static functions. Yada yada. I suppose buggy
    debuggers and error reporters might be confused, but it's the only
    real down side. Isn't it?
    Gene, Jun 2, 2010
    #1
    1. Advertising

  2. Gene

    Ben Pfaff Guest

    Gene <> writes:

    > I guess I'll ask the obvious question. Why not just #include
    > "partIII.c" within partII.c ? It's a bit crufty, but in this manner,
    > the static bodies are exposed for inlining even with a primitive
    > compiler. The name space stays clean. You can avoide top-declaring
    > prototypes for the static functions. Yada yada. I suppose buggy
    > debuggers and error reporters might be confused, but it's the only
    > real down side. Isn't it?


    One of the benefits of (static) libraries is that linkers can
    omit object files that contain no referenced symbols. The more
    functions defined in a single translation unit, the less useful
    this becomes.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jun 3, 2010
    #2
    1. Advertising

  3. Gene

    Gene Guest

    On Jun 3, 12:01 am, (Richard Harter) wrote:
    > On Wed, 2 Jun 2010 14:49:52 -0700 (PDT), Gene
    >
    > <> wrote:
    > >On Jun 2, 12:00=A0pm, (Richard Harter) wrote:

    >
    > [snip problem statement]
    >
    >
    >
    > >I know it's probably inconsequential in practice, but introducing a
    > >runtime overhead (e.g. cache burden for the function pointers) to
    > >support static structure is unsatisfying.

    >
    > >I guess I'll ask the obvious question.  Why not just #include
    > >"partIII.c" within partII.c ?   It's a bit crufty, but in this manner,
    > >the static bodies are exposed for inlining even with a primitive
    > >compiler.  The name space stays clean. You can avoide top-declaring
    > >prototypes for the static functions. Yada yada.  I suppose buggy
    > >debuggers and error reporters might be confused, but it's the only
    > >real down side.  Isn't it?

    >
    > Excuse me while I go into a software orthodoxy panic attack.  The
    > entire concept offends and yet ... it makes sense.  There is the
    > objection that it might involve multiple compilations of
    > something that need only be compiled once.  


    Yet if you get the make dependencies right you ought to avoid this.
    Certainly the situation can be made no worse than the single file you
    started with...

    I had the same panic attack but eventually got over it. Crufty (a
    favorite term due to Peter Wayner, 1991) it is. But no worse than
    preprocessor abuse present in no less than Stahlman's gcc...
    Gene, Jun 3, 2010
    #3
  4. Gene

    Mark Guest

    Ben Pfaff wrote:
    > One of the benefits of (static) libraries is that linkers can
    > omit object files that contain no referenced symbols. The more
    > functions defined in a single translation unit, the less useful
    > this becomes.


    So if each function is implemented in its own object file, it'd more
    efficient for a static library? Isn't it the same approach used for creating
    archives (what is done by GNU ar utility) ?

    --
    Mark
    Mark, Jun 4, 2010
    #4
  5. Gene

    Ben Pfaff Guest

    "Mark" <> writes:

    > Ben Pfaff wrote:
    >> One of the benefits of (static) libraries is that linkers can
    >> omit object files that contain no referenced symbols. The more
    >> functions defined in a single translation unit, the less useful
    >> this becomes.

    >
    > So if each function is implemented in its own object file, it'd more
    > efficient for a static library?


    Yes, that is one common approach.

    > Isn't it the same approach used for creating archives (what is
    > done by GNU ar utility) ?


    An archive create by "ar" *is* a static library.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Jun 4, 2010
    #5
  6. Gene

    Tim Rentsch Guest

    Gene <> writes:

    > On Jun 2, 12:00 pm, (Richard Harter) wrote:
    >> My question of the moment is about splitting large source code
    >> files. For those who want to see real code an example may be
    >> found athttp://home.tiac.net/~cri_a/san/source_code/projects/dfe_engine/dfe_e...
    >>
    >> (Warning: there is no internal documentation - if it was hard to
    >> write, it should be hard to read. For the current discussion it
    >> doesn't matter what's going on; however I will award five jelly
    >> bean points and a gold star to anyone who wants to slog through
    >> it.)
    >>
    >> This file has a simple superstructure with three parts. The
    >> first part consists of declarations, typedefs, etc. The second
    >> part defines public functions, i.e. functions that are visible
    >> outside the file. In the reference file they are an API. The
    >> third part defines private functions, i.e. functions not visible
    >> outside the file. They all are declared static.
    >>
    >> This is a very simple file structure, one that I find convenient.
    >> It works nicely when a single file suffices. What I would like
    >> to do is split the file. Part I goes into an include file.
    >> Parts I and II (public and private) go into separate files. The
    >> issue is how to make the private functions in file II visible to
    >> the public functions in file I.
    >>
    >> One way to do this is to create a struct that holds pointers to
    >> all of the private functions. A more elaborate scheme declares
    >> function pointer variables in the part I file and has behind the
    >> scene code to copy the actual function pointers from the part II
    >> file into the part I file.
    >>
    >> Incidentally, one reason for wanting to do the split is that I
    >> want several "Part I" files that do different things.
    >>
    >> Any and all suggestions will be appreciated.
    >>

    >
    > I know it's probably inconsequential in practice, but introducing a
    > runtime overhead (e.g. cache burden for the function pointers) to
    > support static structure is unsatisfying.
    >
    > I guess I'll ask the obvious question. Why not just #include
    > "partIII.c" within partII.c ? It's a bit crufty, but in this manner,
    > the static bodies are exposed for inlining even with a primitive
    > compiler. The name space stays clean. You can avoide top-declaring
    > prototypes for the static functions. Yada yada. I suppose buggy
    > debuggers and error reporters might be confused, but it's the only
    > real down side. Isn't it?


    I would be wary of adopting such an approach, worrying about the
    "out of sync" condition arising. That is, the private code is
    compiled multiple times, and replicated in each of the "outer"
    (public) modules that use it. In my experience when such things
    are done, the replicated pieces will get out of sync at some
    point, no matter how careful one is with compiling, makefiles,
    etc, and code that's assumed to be the same in several places
    will in fact be different in one or more places. The result is
    at best confusion and irritation; more likely it's lots of
    wasted time and hard to diagnose crashes. Of course this problem
    can be avoided by always recompiling everything whenever anything
    has to be compiled, but at some point it always seems to happen
    that someone will make an exception "just this once". For that
    reason I would be reluctant to go down this path, feeling like I
    was deliberately leaving booby traps lying around just waiting
    for someone to fall into them.
    Tim Rentsch, Jun 19, 2010
    #6
    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. John Ericson
    Replies:
    0
    Views:
    423
    John Ericson
    Jul 19, 2003
  2. Mark
    Replies:
    0
    Views:
    440
  3. John Dibling
    Replies:
    0
    Views:
    411
    John Dibling
    Jul 19, 2003
  4. Ben Pfaff

    Re: Splitting a source code file

    Ben Pfaff, Jun 2, 2010, in forum: C Programming
    Replies:
    27
    Views:
    662
    Richard Bos
    Jun 9, 2010
  5. Luke Worth

    Splitting source code

    Luke Worth, Jul 12, 2005, in forum: Ruby
    Replies:
    7
    Views:
    105
    Austin Ziegler
    Jul 13, 2005
Loading...

Share This Page