Modularisation

Discussion in 'C Programming' started by Steffen Loringer, Oct 5, 2005.

  1. Hi,

    can anyone recommend a good wbeppage concerning modularisation of C
    programs into different files?

    Thanks to all of you
    Steffen
     
    Steffen Loringer, Oct 5, 2005
    #1
    1. Advertising

  2. "Steffen Loringer" <> wrote in message
    news:...
    > can anyone recommend a good wbeppage concerning modularisation of C
    > programs into different files?


    But what is the problem? Normally this is done by separating more or less
    independent portions of the code into separate files. Just that. Of course
    that may involve quite some coding, not just copy'n'pasting...
    But as far as C goes, what's the problem?

    Alex
     
    Alexei A. Frounze, Oct 5, 2005
    #2
    1. Advertising

  3. There is no real problem. But there may be rules for good coding etc...
    I separated my functions "by function part of the program" into header
    *.h and source *.c files.
    I have to include many libraries for each *.h and *.c, does this make my
    executable bigger at the end??

    Thanks for your reply, Alexei!

    Alexei A. Frounze schrieb:

    > "Steffen Loringer" <> wrote in message
    > news:...
    >
    >>can anyone recommend a good wbeppage concerning modularisation of C
    >>programs into different files?

    >
    >
    > But what is the problem? Normally this is done by separating more or less
    > independent portions of the code into separate files. Just that. Of course
    > that may involve quite some coding, not just copy'n'pasting...
    > But as far as C goes, what's the problem?
    >
    > Alex
    >
    >
     
    Steffen Loringer, Oct 5, 2005
    #3
  4. *.h should contain public info that's intended for use by the caller, e.g.:
    - macros
    - type definitions
    - inline functinos (you may need to declare them as "static inline" --
    depends on the compiler I guess)
    - externs
    *.c should contain everything else that's internal and not to be exposed to
    the outer world.
    This is as far as the .h vs .c goes.
    But then you also should separate the code semantically, put in different .?
    files the code for different things, e.g.:
    - input/output management (better to make an abstract API for portability)
    - system layer (synchronization primitives, interprocess communication and
    everything else that's system-specific -- better to make an abstract API for
    portability)
    - general purpose data structure management (e.g. searching, sorting, lists,
    trees, hashtables, etc)
    - task-oriented data processing (can be anything, ranging from text
    processing and conversion to signal processing (audio, video, whatever),
    data compression/encryption, various computation tasks -- every distinct set
    of operations deserves its own file (or set of a few files))
    - auxiliary/miscellaneous/helper functions of small importance and maybe
    frequent use

    I'm not sure what libraries you're talking about, but separating the code
    into several compilaion units must not make it any bigger. Actually, it can
    make it smaller (if you put the code that may not be used at all into a
    separate .c file -- its object code won't be linked in unless necessary).
    Each library and object file is linked only once unless your tools are
    broken or allow some degree of misuse.

    Mind you, separation of the code into distinct units, better as much
    independednt as possible, allows for simpler maintainance, testing and
    debugging. That's the primary reason to do such a thing. And don't forget
    that recompilation of a single huge .c file will take longer than
    recompilation of a small one.

    Alex
    P.S. please don't top post.
    A: Yep, Alice in the Wonderland had first to serve the cake out to a few
    persons and only then cut it in parts.
    Q: Really? I don't get it. Could you give me an example?
    A: Because it makes the flow of events complicated
    Q: Why top posting is bad?

    "Steffen Loringer" <> wrote in message
    news:...
    > There is no real problem. But there may be rules for good coding etc...
    > I separated my functions "by function part of the program" into header
    > *.h and source *.c files.
    > I have to include many libraries for each *.h and *.c, does this make my
    > executable bigger at the end??
    >
    > Thanks for your reply, Alexei!
    >
    > Alexei A. Frounze schrieb:
    >
    > > "Steffen Loringer" <> wrote in message
    > > news:...
    > >
    > >>can anyone recommend a good wbeppage concerning modularisation of C
    > >>programs into different files?

    > >
    > >
    > > But what is the problem? Normally this is done by separating more or

    less
    > > independent portions of the code into separate files. Just that. Of

    course
    > > that may involve quite some coding, not just copy'n'pasting...
    > > But as far as C goes, what's the problem?
    > >
    > > Alex
    > >
    > >

    >
     
    Alexei A. Frounze, Oct 5, 2005
    #4
  5. Alexei A. Frounze wrote:
    <snip>

    > *.c should contain everything else that's internal and not to be exposed to
    > the outer world.


    Oh really? Then where are funcations with external linkage defined?

    <snip>
    >
    > I'm not sure what libraries you're talking about, but separating the code
    > into several compilaion units must not make it any bigger. Actually, it can
    > make it smaller (if you put the code that may not be used at all into a
    > separate .c file -- its object code won't be linked in unless necessary).


    Misleading at best. This will generally *not* occur unless the linker
    is told to, or the group of object files are made into a static archive
    before linking.

    Also, for a discussion about executable sizes to be meaningful, you
    have to consider the effect of shared libraries if the system in
    question uses them.

    > Each library and object file is linked only once unless your tools are
    > broken or allow some degree of misuse.


    Again, misleading. Depends on the circumstance, and how your linker
    handles mutually referential libraries.

    >
    > Mind you, separation of the code into distinct units, better as much
    > independednt as possible, allows for simpler maintainance, testing and
    > debugging. That's the primary reason to do such a thing.


    Agreed.

    > And don't forget
    > that recompilation of a single huge .c file will take longer than
    > recompilation of a small one.


    Not by too much, on today's systems.


    Mark F. Haigh
     
    Mark F. Haigh, Oct 5, 2005
    #5
  6. Alexei A. Frounze wrote:
    > "Steffen Loringer" <> wrote in message
    > news:...
    >
    >>can anyone recommend a good wbeppage concerning modularisation of C
    >>programs into different files?

    >
    >
    > But what is the problem? Normally this is done by separating more or less
    > independent portions of the code into separate files. Just that. Of course
    > that may involve quite some coding, not just copy'n'pasting...
    > But as far as C goes, what's the problem?


    Since modularization is one of the weakest points of C you need some
    good rules for how to do it. Still, even with an appropriate
    modularization technique there is no way to declare types or (true)
    constants with file scope (compare with Modula and Oberon).


    August
     
    August Karlstrom, Oct 5, 2005
    #6
  7. Steffen Loringer

    Eric Sosman Guest

    August Karlstrom wrote:

    > Alexei A. Frounze wrote:
    >
    >> "Steffen Loringer" <> wrote in message
    >> news:...
    >>
    >>> can anyone recommend a good wbeppage concerning modularisation of C
    >>> programs into different files?

    >>
    >> But what is the problem? Normally this is done by separating more or less
    >> independent portions of the code into separate files. Just that. Of
    >> course
    >> that may involve quite some coding, not just copy'n'pasting...
    >> But as far as C goes, what's the problem?

    >
    > Since modularization is one of the weakest points of C you need some
    > good rules for how to do it. Still, even with an appropriate
    > modularization technique there is no way to declare types or (true)
    > constants with file scope (compare with Modula and Oberon).


    It's easy to declare types with file scope in C: Just Do It.

    /*** foo.c ***/
    struct s { int this; double that; }
    struct s instance = { 42, 3.14 };
    int getThis(struct s *sptr) {
    return s->this;
    }
    /* More code using the `struct s' type freely */

    /*** bar.c ***/
    struct s anotherinstance = { -1, 98.6 };
    /* sorry; won't compile: this code is outside the
    scope of the `struct s' type declaration */

    Constants are, I admit, harder to do. There's #define, but
    prior to C99 it couldn't really declare a "constant" of compound
    type other than string. There are enum identifiers, but they're
    limited to integer constants. However, I don't see what these
    peculiarities have to do with modularization.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Oct 5, 2005
    #7
  8. Steffen Loringer

    pete Guest

    Alexei A. Frounze wrote:
    >
    > *.h should contain public info that's intended for use by the caller, e.g.:
    > - macros
    > - type definitions
    > - inline functinos (you may need to declare them as "static inline" --
    > depends on the compiler I guess)


    Why put inline functions in the .h file?

    --
    pete
     
    pete, Oct 5, 2005
    #8
  9. Steffen Loringer

    pete Guest

    Mark F. Haigh wrote:
    >
    > Alexei A. Frounze wrote:
    > <snip>
    >
    > > *.c should contain everything else
    > > that's internal and not to be exposed to
    > > the outer world.

    >
    > Oh really? Then where are funcations with external linkage defined?


    All function definitions and object definitions
    belong in the .c files, regardless of linkage,
    as far as I know.

    --
    pete
     
    pete, Oct 5, 2005
    #9
  10. "Mark F. Haigh" <> wrote in message
    news:...
    > Alexei A. Frounze wrote:
    > <snip>
    >
    > > *.c should contain everything else that's internal and not to be exposed

    to
    > > the outer world.

    >
    > Oh really? Then where are funcations with external linkage defined?


    Exactly what do you mean?

    > <snip>
    > >
    > > I'm not sure what libraries you're talking about, but separating the

    code
    > > into several compilaion units must not make it any bigger. Actually, it

    can
    > > make it smaller (if you put the code that may not be used at all into a
    > > separate .c file -- its object code won't be linked in unless

    necessary).
    >
    > Misleading at best. This will generally *not* occur unless the linker
    > is told to,


    It shouldn't be told to. Why linking a module into executable if out of this
    module nothing is referenced, neither code nor data? I'd say misleading is
    gluing in unuseful code and data.

    > or the group of object files are made into a static archive
    > before linking.


    I don't know what you mean.

    > Also, for a discussion about executable sizes to be meaningful, you
    > have to consider the effect of shared libraries if the system in
    > question uses them.


    Indeed, I did not consider shared libraries in the response, so thank's for
    the addition. The original poster didn't mention them, though...

    > > Each library and object file is linked only once unless your tools are
    > > broken or allow some degree of misuse.

    >
    > Again, misleading. Depends on the circumstance, and how your linker
    > handles mutually referential libraries.


    I don't know if misleading is one of your favorite self-and-all-explanatory
    words... So what if lib1 references lib2 and that one references lib1 back?
    Should I get 2 copies of the same code or data (from either lib)? Is that's
    what you're saying? I was replying from the size standpoint when saying
    *linked once*, I meant getting one instance of say fread() in the executable
    and not two or more. I don't know how exactly I should interpret this your
    comment, whether you're just uncomfortable with my meaning of "linked once"
    and want to tell that the linker will have to go back and forth to resolve
    the undefined references in the crossreferencing libraries or want to say
    something else but don't say that... If it's the former, then that's
    entirely different thing here and to me it has nothing to do with the size
    of the code. If it's the latter, then please explain or I'm starting to feel
    that your comment is misleading at best too.

    > > Mind you, separation of the code into distinct units, better as much
    > > independednt as possible, allows for simpler maintainance, testing and
    > > debugging. That's the primary reason to do such a thing.

    >
    > Agreed.


    Strange. I thought there would be not a single point of agreement. ;)

    > > And don't forget
    > > that recompilation of a single huge .c file will take longer than
    > > recompilation of a small one.

    >
    > Not by too much, on today's systems.


    Which means you've never been involved in projects whose size and complexity
    required more horsepower for compilation than was available. Or you think
    everyone's got a today's super computer. Either way this your assertion is
    very doubtful.

    Alex
     
    Alexei A. Frounze, Oct 5, 2005
    #10
  11. "pete" <> wrote in message
    news:...
    > Alexei A. Frounze wrote:
    > >
    > > *.h should contain public info that's intended for use by the caller,

    e.g.:
    > > - macros
    > > - type definitions
    > > - inline functinos (you may need to declare them as "static inline" --
    > > depends on the compiler I guess)

    >
    > Why put inline functions in the .h file?


    How would you share an inline function between 2 .c files? Except by having
    2 copies of it, only through an .h file. Just like a common macros.

    Alex
     
    Alexei A. Frounze, Oct 5, 2005
    #11
  12. Eric Sosman wrote:
    > August Karlstrom wrote:
    >> Since modularization is one of the weakest points of C you need some
    >> good rules for how to do it. Still, even with an appropriate
    >> modularization technique there is no way to declare types or (true)
    >> constants with file scope (compare with Modula and Oberon).

    >
    >
    > It's easy to declare types with file scope in C: Just Do It.


    Yes, you are right (and I was wrong). However, this is an example of an
    irregularity in C -- of the declarations

    struct s { int m; };
    int n;
    void f(void);

    `struct s' has file scope, but n and f has global scope (require `static').


    August
     
    August Karlstrom, Oct 5, 2005
    #12
  13. Steffen Loringer

    Eric Sosman Guest

    August Karlstrom wrote On 10/05/05 11:44,:
    > Eric Sosman wrote:
    >
    >>August Karlstrom wrote:
    >>
    >>>Since modularization is one of the weakest points of C you need some
    >>>good rules for how to do it. Still, even with an appropriate
    >>>modularization technique there is no way to declare types or (true)
    >>>constants with file scope (compare with Modula and Oberon).

    >>
    >>
    >> It's easy to declare types with file scope in C: Just Do It.

    >
    >
    > Yes, you are right (and I was wrong). However, this is an example of an
    > irregularity in C -- of the declarations
    >
    > struct s { int m; };
    > int n;
    > void f(void);
    >
    > `struct s' has file scope, but n and f has global scope (require `static').


    Right. Or more precisely, n and f have file scope
    but external linkage. Other modules (sorry, "translation
    units") can refer to them, but only by re-declaring them;
    n and f are not automatically in scope for other modules.

    Ever since I first encountered C in the mid-1970's
    I've felt that the language took the wrong default for
    "undecorated" declarations at file scope. That is, I
    think it would have been better if n and f were "implicitly
    static" (in today's terms) and that an identifier would have
    external linkage only if declared with a keyword like `public'
    or `export'. Obviously, dmr did not feel that way -- and
    it's not really a huge problem; I just reflexively put
    `static' on nearly everything. The habit is so strong that
    even when I'm writing tiny little one-file programs the
    only externally-linked identifier I declare is main().

    --
     
    Eric Sosman, Oct 5, 2005
    #13
  14. Steffen Loringer

    Mike Wahler Guest

    "August Karlstrom" <> wrote in message
    news:4xS0f.35332$...
    > Eric Sosman wrote:
    >> August Karlstrom wrote:
    >>> Since modularization is one of the weakest points of C you need some
    >>> good rules for how to do it. Still, even with an appropriate
    >>> modularization technique there is no way to declare types or (true)
    >>> constants with file scope (compare with Modula and Oberon).

    >>
    >>
    >> It's easy to declare types with file scope in C: Just Do It.

    >
    > Yes, you are right (and I was wrong). However, this is an example of an
    > irregularity in C -- of the declarations
    >
    > struct s { int m; };
    > int n;
    > void f(void);
    >
    > `struct s' has file scope, but n and f has global scope (require
    > `static').


    I think you need to sort out in your mind the difference between
    scope and linkage.

    -Mike
     
    Mike Wahler, Oct 5, 2005
    #14
  15. Alexei A. Frounze wrote:
    > "Mark F. Haigh" <> wrote in message
    > news:...
    > > Alexei A. Frounze wrote:
    > > <snip>
    > >
    > > > *.c should contain everything else that's internal and not to be exposed

    > to
    > > > the outer world.

    > >
    > > Oh really? Then where are funcations with external linkage defined?

    >
    > Exactly what do you mean?


    Functions that are "exposed to the outer world" (external linkage) have
    to be defined somewhere. They're declared in the headers, but they are
    generally defined in .c files.

    >
    > > <snip>
    > > >
    > > > I'm not sure what libraries you're talking about, but separating the

    > code
    > > > into several compilaion units must not make it any bigger. Actually, it

    > can
    > > > make it smaller (if you put the code that may not be used at all into a
    > > > separate .c file -- its object code won't be linked in unless

    > necessary).
    > >
    > > Misleading at best. This will generally *not* occur unless the linker
    > > is told to,

    >
    > It shouldn't be told to. Why linking a module into executable if out of this
    > module nothing is referenced, neither code nor data? I'd say misleading is
    > gluing in unuseful code and data.


    Like it or not, this behavior is common for a variety of reasons. If
    you're building a library, then nearly all the code looks "unused" from
    the linker's point of view.

    >
    > > or the group of object files are made into a static archive
    > > before linking.

    >
    > I don't know what you mean.


    The semantics of linking against static libraries and object files
    differ. Generally speaking, linkers pick and choose from libraries but
    include the whole of object files (unless instructed not to). Since
    this is very platform-specific (and OT), I'll leave it at that.

    <snip>
    >
    > > > Each library and object file is linked only once unless your tools are
    > > > broken or allow some degree of misuse.

    > >
    > > Again, misleading. Depends on the circumstance, and how your linker
    > > handles mutually referential libraries.

    >
    > I don't know if misleading is one of your favorite self-and-all-explanatory
    > words... So what if lib1 references lib2 and that one references lib1 back?
    > Should I get 2 copies of the same code or data (from either lib)? Is that's
    > what you're saying? I was replying from the size standpoint when saying
    > *linked once*, I meant getting one instance of say fread() in the executable
    > and not two or more. I don't know how exactly I should interpret this your
    > comment, whether you're just uncomfortable with my meaning of "linked once"
    > and want to tell that the linker will have to go back and forth to resolve
    > the undefined references in the crossreferencing libraries or want to say
    > something else but don't say that... If it's the former, then that's
    > entirely different thing here and to me it has nothing to do with the size
    > of the code. If it's the latter, then please explain or I'm starting to feel
    > that your comment is misleading at best too.


    Files are often linked more than once. This is commonly known as
    partial (or relocatable) linking. Mutually referential libraries need
    to be repeatedly linked until there are no further unresolved symbols.
    That's why your statment "each library and object file is linked only
    once" is incorrect.

    Understand that in most cases on non-embedded platforms, there will be
    _no_ instances of library code in the executable. There will just be
    an undefined symbol that is patched up by the dynamic linker/loader at
    run time. To use your example, there would be no instances of fread()
    in _any_ executable, one instance of fread() in a shared library, and
    all executables use the same instance.

    Once again, this is OT, so I will stop there.

    <snip>
    >
    > > > And don't forget
    > > > that recompilation of a single huge .c file will take longer than
    > > > recompilation of a small one.

    > >
    > > Not by too much, on today's systems.

    >
    > Which means you've never been involved in projects whose size and complexity
    > required more horsepower for compilation than was available. Or you think
    > everyone's got a today's super computer. Either way this your assertion is
    > very doubtful.


    I regularly deal with the internals of compiling and linking
    multi-million line codebases, often distributed across farms of
    multi-processor machines. Compilation time of large vs. small C files
    do not typically differ by more than a second on any post-Pentium III
    machine.


    Mark F. Haigh
     
    Mark F. Haigh, Oct 5, 2005
    #15
  16. "Mark F. Haigh" <> wrote in message
    news:...
    > Alexei A. Frounze wrote:
    > > "Mark F. Haigh" <> wrote in message
    > > news:...
    > > > Alexei A. Frounze wrote:
    > > > <snip>
    > > >
    > > > > *.c should contain everything else that's internal and not to be

    exposed
    > > to
    > > > > the outer world.
    > > >
    > > > Oh really? Then where are funcations with external linkage defined?

    > >
    > > Exactly what do you mean?

    >
    > Functions that are "exposed to the outer world" (external linkage) have
    > to be defined somewhere. They're declared in the headers, but they are
    > generally defined in .c files.


    I don't see where this your statement contradicts mine. I might misused some
    word (define vs declare or whatever -- forgive my bad English), but that's
    what I meant. But I explicitly wrote "externs" in the list below .h -- see
    my previous post.

    ???

    > > > > I'm not sure what libraries you're talking about, but separating the

    > > code
    > > > > into several compilaion units must not make it any bigger. Actually,

    it
    > > can
    > > > > make it smaller (if you put the code that may not be used at all

    into a
    > > > > separate .c file -- its object code won't be linked in unless

    > > necessary).
    > > >
    > > > Misleading at best. This will generally *not* occur unless the linker
    > > > is told to,

    > >
    > > It shouldn't be told to. Why linking a module into executable if out of

    this
    > > module nothing is referenced, neither code nor data? I'd say misleading

    is
    > > gluing in unuseful code and data.

    >
    > Like it or not, this behavior is common for a variety of reasons. If
    > you're building a library, then nearly all the code looks "unused" from
    > the linker's point of view.


    The original poster asked about "modularization of C programs" meaning that
    he's making programs, not libraries. Unless you extend programs to cover
    libraries too, this is irrelevant. But I do acknowledge your ... let's look
    up the dictionary ... punctiliousness. Or pedantry. Pick whichever you like
    better :)

    > > > or the group of object files are made into a static archive
    > > > before linking.

    > >
    > > I don't know what you mean.

    >
    > The semantics of linking against static libraries and object files
    > differ. Generally speaking, linkers pick and choose from libraries but
    > include the whole of object files (unless instructed not to). Since
    > this is very platform-specific (and OT), I'll leave it at that.


    What do you mean by "the whole of object files"? Do you mean *all* files or
    whole files (e.g. a file in whole/entire file)? And unless that particular
    linker treats a library as something more special that the collection of the
    object files it consists of (for what reason would it?), there is no
    difference.

    > > > > Each library and object file is linked only once unless your tools

    are
    > > > > broken or allow some degree of misuse.
    > > >
    > > > Again, misleading. Depends on the circumstance, and how your linker
    > > > handles mutually referential libraries.

    > >
    > > I don't know if misleading is one of your favorite

    self-and-all-explanatory
    > > words... So what if lib1 references lib2 and that one references lib1

    back?
    > > Should I get 2 copies of the same code or data (from either lib)? Is

    that's
    > > what you're saying? I was replying from the size standpoint when saying
    > > *linked once*, I meant getting one instance of say fread() in the

    executable
    > > and not two or more. I don't know how exactly I should interpret this

    your
    > > comment, whether you're just uncomfortable with my meaning of "linked

    once"
    > > and want to tell that the linker will have to go back and forth to

    resolve
    > > the undefined references in the crossreferencing libraries or want to

    say
    > > something else but don't say that... If it's the former, then that's
    > > entirely different thing here and to me it has nothing to do with the

    size
    > > of the code. If it's the latter, then please explain or I'm starting to

    feel
    > > that your comment is misleading at best too.

    >
    > Files are often linked more than once. This is commonly known as
    > partial (or relocatable) linking. Mutually referential libraries need
    > to be repeatedly linked until there are no further unresolved symbols.


    Right.

    > That's why your statment "each library and object file is linked only
    > once" is incorrect.


    So, with all your pedantry, can you forgive me my English? :)

    > Understand that in most cases on non-embedded platforms, there will be
    > _no_ instances of library code in the executable. There will just be
    > an undefined symbol that is patched up by the dynamic linker/loader at
    > run time. To use your example, there would be no instances of fread()
    > in _any_ executable, one instance of fread() in a shared library, and
    > all executables use the same instance.


    That is all correct.

    > Once again, this is OT, so I will stop there.


    :) I've already suggested not covering the DLLs as there was no inquiry to.
    And I've just suggested not making the term library subset of the term
    program. To lawyers these would probably the same thing, to us there's a
    difference.

    > > > > And don't forget
    > > > > that recompilation of a single huge .c file will take longer than
    > > > > recompilation of a small one.
    > > >
    > > > Not by too much, on today's systems.

    > >
    > > Which means you've never been involved in projects whose size and

    complexity
    > > required more horsepower for compilation than was available. Or you

    think
    > > everyone's got a today's super computer. Either way this your assertion

    is
    > > very doubtful.

    >
    > I regularly deal with the internals of compiling and linking
    > multi-million line codebases, often distributed across farms of
    > multi-processor machines. Compilation time of large vs. small C files
    > do not typically differ by more than a second on any post-Pentium III
    > machine.


    Then I may only tell you that you're a lucky guy to have all that now and as
    maybe all the time before.

    Since I'm seeing not much of a disagreement between us, just you being
    pedantic, maybe we shall finish this thread right here? I guess the original
    poster is already satisfied with the details.

    Alex
     
    Alexei A. Frounze, Oct 6, 2005
    #16
  17. Alexei A. Frounze wrote:
    > "Mark F. Haigh" <> wrote in message
    > > Alexei A. Frounze wrote:
    > > > "Mark F. Haigh" <> wrote in message
    > > > > Alexei A. Frounze wrote:
    > > > > <snip>
    > > > >
    > > > > > *.c should contain everything else that's internal and not to be

    > exposed
    > > > to
    > > > > > the outer world.
    > > > >
    > > > > Oh really? Then where are funcations with external linkage defined?
    > > >
    > > > Exactly what do you mean?

    > >
    > > Functions that are "exposed to the outer world" (external linkage) have
    > > to be defined somewhere. They're declared in the headers, but they are
    > > generally defined in .c files.

    >
    > I don't see where this your statement contradicts mine. I might misused some
    > word (define vs declare or whatever -- forgive my bad English), but that's
    > what I meant. But I explicitly wrote "externs" in the list below .h -- see
    > my previous post.
    >


    "Declaration" and "definition" have precise meanings in C. If you
    don't understand the difference, look it up.

    > ???
    >
    > > > > > I'm not sure what libraries you're talking about, but separating the
    > > > code
    > > > > > into several compilaion units must not make it any bigger. Actually,

    > it
    > > > can
    > > > > > make it smaller (if you put the code that may not be used at all

    > into a
    > > > > > separate .c file -- its object code won't be linked in unless
    > > > necessary).
    > > > >
    > > > > Misleading at best. This will generally *not* occur unless the linker
    > > > > is told to,
    > > >
    > > > It shouldn't be told to. Why linking a module into executable if out of

    > this
    > > > module nothing is referenced, neither code nor data? I'd say misleading

    > is
    > > > gluing in unuseful code and data.

    > >
    > > Like it or not, this behavior is common for a variety of reasons. If
    > > you're building a library, then nearly all the code looks "unused" from
    > > the linker's point of view.

    >
    > The original poster asked about "modularization of C programs" meaning that
    > he's making programs, not libraries. Unless you extend programs to cover
    > libraries too, this is irrelevant. But I do acknowledge your ... let's look
    > up the dictionary ... punctiliousness. Or pedantry. Pick whichever you like
    > better :)


    Hmmm. You post incorrect information with a false air of authority,
    then whine "pedantry!" when corrected. While you have the dictionary
    open, look up the word "wanker", as you're starting to become one.


    >
    > > > > or the group of object files are made into a static archive
    > > > > before linking.
    > > >
    > > > I don't know what you mean.

    > >
    > > The semantics of linking against static libraries and object files
    > > differ. Generally speaking, linkers pick and choose from libraries but
    > > include the whole of object files (unless instructed not to). Since
    > > this is very platform-specific (and OT), I'll leave it at that.

    >
    > What do you mean by "the whole of object files"? Do you mean *all* files or
    > whole files (e.g. a file in whole/entire file)? And unless that particular
    > linker treats a library as something more special that the collection of the
    > object files it consists of (for what reason would it?), there is no
    > difference.


    Static libraries _are_ different than the collection of object files it
    consists of. If you link against a static library, you will not link
    in unused object files. If you link against an object file, you will
    include everything, whether it's used or not.

    <remainder snipped>


    Mark F. Haigh
     
    Mark F. Haigh, Oct 6, 2005
    #17
    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.

Share This Page