About libraries and headers

Discussion in 'C Programming' started by tsoukase@gmail.com, Apr 9, 2005.

  1. Guest

    Hello,

    two questions:
    1) Why is a library a collection of compiled source-files
    while each header-file is a single source? Would it be more
    efficient if they were both either compiled or not?
    Could a "header-library" exist?
    2) Why do libraries have extensions .a and .so and
    modules .o, which should be reserved for cc -c output?
    Would it be better: module.m, lib.sl, lib.dl or something
    alike?
    Are these forms an inheritance from C's old-time or do
    they provide a specific functionality?

    Evangelos Tsoukas
    , Apr 9, 2005
    #1
    1. Advertising

  2. On 9 Apr 2005 08:36:16 -0700,
    <> wrote:

    > two questions:
    > 1) Why is a library a collection of compiled source-files
    > while each header-file is a single source? Would it be more
    > efficient if they were both either compiled or not?


    Libraries aren't a C concept, they are an operating system concept. C
    has "translation units" which produce something which can eventially be
    executed, but what that "something" is may not be a library. The only
    "library" in the standard is the collection of functions specified as
    part of the implementation, but they may not exist as an external object
    'library', they could for instance be code inserted by the compiler at
    the point they are called (and indeed some functions are often
    implemented like that for optimisation).

    > Could a "header-library" exist?


    Yes, if your translation environment supports it. For instance the
    Borland compiler has a facility to "pre-compile" header files where it
    knows that nothing has changed. Some Unix systems have had a concept of
    a "source library" (indeed, I believe that ar still supports this) and a
    compiler could accept such a thing as the place where it looks for
    header files (I don't know of any compiler which does). It would even
    be possible to combine object and source in the same library so that the
    compiler would search it twice, once for the header files and then to
    find the object files to link. Again, I don't know of any compiler
    which supports that.

    However, header files contain code which depends on context, in
    particular on what macros are defined. For instance, take a simple
    header file:

    fred.h:

    #ifdef USE_DOUBLE
    typedef double MyType;
    #else
    typedef float MyType;
    #endif

    Depending on whether the macro USE_DOUBLE is defined the header file is
    included, MyType will be defined as either double or float types
    (probably because the programmer wants to optimise for space or
    resomution). If it were compiled then only one of those could be
    selected.

    > 2) Why do libraries have extensions .a and .so and
    > modules .o, which should be reserved for cc -c output?


    They don't. On some systems the types are .lib, .dll and .obj
    respecxtively. But what do you mean by 'modules' other than compiled C
    (or some other language) output?

    > Would it be better: module.m, lib.sl, lib.dl or something
    > alike?
    > Are these forms an inheritance from C's old-time or do
    > they provide a specific functionality?


    They are determined by your system and compiler, nothing more. There is
    no standard for them (except that they are what Unix has used for a long
    time and masses of code would cease to build if someone decided to use
    different extensions).

    All of this (except why header files are not usually compiled) is off
    topic for comp.lang.c, because it is nothing to do with C as a language,
    it's a feature of the translation environment (compiler, linker, loader,
    operating system, etc.). You need to ask on a newsgroup specific to
    your system (comp.unix.programmer for Unix, for instance) and possibly
    ask on a vendor-specific newsgroup or mailing list.

    But I suspect "because it's always been done that way" is a big reason
    for naming...

    Chris C
    Chris Croughton, Apr 9, 2005
    #2
    1. Advertising

  3. Artie Gold Guest

    wrote:
    > Hello,
    >
    > two questions:
    > 1) Why is a library a collection of compiled source-files
    > while each header-file is a single source? Would it be more
    > efficient if they were both either compiled or not?
    > Could a "header-library" exist?


    From the standpoint of the C *language* a library is a chunk of code
    you can use (and the standard does not specify what the mechanism is).
    Headers contain *declarations* of functions, extern-ed variables and
    macros (and sometimes preprocessor directives) that provide the
    information necessary for your code to use the library.

    There is the notion of "precompiled headers", but that's an
    implementation detail.

    > 2) Why do libraries have extensions .a and .so and
    > modules .o, which should be reserved for cc -c output?
    > Would it be better: module.m, lib.sl, lib.dl or something
    > alike?
    > Are these forms an inheritance from C's old-time or do
    > they provide a specific functionality?


    Said file extensions are platform specific and not germane here.


    HTH,
    --ag

    --
    Artie Gold -- Austin, Texas
    http://it-matters.blogspot.com (new post 12/5)
    http://www.cafepress.com/goldsays
    Artie Gold, Apr 9, 2005
    #3
  4. CBFalconer Guest

    wrote:
    >
    > two questions:
    > 1) Why is a library a collection of compiled source-files
    > while each header-file is a single source? Would it be more
    > efficient if they were both either compiled or not?
    > Could a "header-library" exist?
    > 2) Why do libraries have extensions .a and .so and
    > modules .o, which should be reserved for cc -c output?
    > Would it be better: module.m, lib.sl, lib.dl or something
    > alike?
    > Are these forms an inheritance from C's old-time or do
    > they provide a specific functionality?


    How a library is provided is a matter for the individual system to
    control, and not standardized in any way for the language.
    Therefore it is off-topic here.

    Often libraries are broken into small modules to avoid loading and
    linking unneeded code, while header files can specify the interface
    to a large number of routines at once.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    CBFalconer, Apr 9, 2005
    #4
  5. Joe Wright Guest

    wrote:
    > Hello,
    >
    > two questions:
    > 1) Why is a library a collection of compiled source-files
    > while each header-file is a single source? Would it be more
    > efficient if they were both either compiled or not?


    Probably not. The library was compiled once, maybe several months or
    years ago. The header is indeed source code. It is #include'd in your
    program so that the compiler knows which functions you want and how to
    call them from the libraries. The compiler of your prog.c cannot know
    what modules or libraries will be linked into the final program.

    > Could a "header-library" exist?


    Probably not. See comment above.

    > 2) Why do libraries have extensions .a and .so and
    > modules .o, which should be reserved for cc -c output?


    Because the original developers thought it was a good idea.

    > Would it be better: module.m, lib.sl, lib.dl or something
    > alike?


    Probably not.

    > Are these forms an inheritance from C's old-time or do
    > they provide a specific functionality?


    Yes and yes. The file extensions are well known and exquisitely
    descriptive. Your .m is already .o, .a (archive) is a static library and
    ..so is a shared library. No idea what you think .dl is.
    >
    > Evangelos Tsoukas


    Learn C. Write lots of programs. Ask questions here. Rinse. Repeat.

    --
    Joe Wright mailto:
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Apr 9, 2005
    #5
  6. On 9 Apr 2005 08:36:16 -0700, wrote:

    >
    >Hello,
    >
    >two questions:
    >1) Why is a library a collection of compiled source-files
    >while each header-file is a single source? Would it be more
    >efficient if they were both either compiled or not?
    >Could a "header-library" exist?
    >2) Why do libraries have extensions .a and .so and
    >modules .o, which should be reserved for cc -c output?
    >Would it be better: module.m, lib.sl, lib.dl or something
    >alike?
    >Are these forms an inheritance from C's old-time or do
    >they provide a specific functionality?
    >
    >Evangelos Tsoukas


    You are assuming that the contents of a header file are closely
    related to the contents of a library. The standard header files
    describe the "user interface" to the standard functions (through the
    use of function prototypes or macros), declare some standard types
    (like FILE and size_t using typedef or macros), and provide access to
    standard features (such as errno and stdin, commonly by macros). They
    do not define how the standard functions perform their respective
    tasks. For those systems that provide this, the source is usually
    contained in a separate set of files which the user could use to
    rebuild the functions. It is these separate files, not the headers,
    which are used to build the libraries.

    Header files, if they are even files at all, are used by the compiler.
    Library files are used by the linker.

    The contents of the standard headers are defined by the standard. The
    organization of library files is an implementation detail about which
    the standard says only that they exist.

    For all the standard headers, compiling them would not generate any
    executable code. They basically consist only of declarations and
    preprocessing directives, no object definitions and no function
    definitions. Try compiling a source file like
    /* begin of file */
    #include <stdio.h>
    /* end of file */

    While I don't know of any implementation to do so, there is no reason
    that each library could not be the result of compiling a single source
    file, though obviously not a header. Most would call this an object
    file since the term library is usually used to denote a collection of
    object files.


    <<Remove the del for email>>
    Barry Schwarz, Apr 9, 2005
    #6
  7. Guest

    I think with a carefull study of your writings I can obtain anwers to
    more questions of mine.
    Thank you
    ET
    , Apr 9, 2005
    #7
  8. SM Ryan Guest

    wrote:
    #
    # Hello,
    #
    # two questions:
    # 1) Why is a library a collection of compiled source-files
    # while each header-file is a single source? Would it be more

    Because it is.

    # efficient if they were both either compiled or not?

    Yes, it would.

    # Could a "header-library" exist?

    Yes, it could. For some other languages this already the case.

    C started in more primitive environment, and it is now too late to do massive
    changes without breaking huge amounts of deployed code.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    A bunch of savages in this town.
    SM Ryan, Apr 10, 2005
    #8
  9. CBFalconer Guest

    SM Ryan wrote:
    > wrote:
    > #
    > # Hello,
    > #
    > # two questions:
    > # 1) Why is a library a collection of compiled source-files
    > # while each header-file is a single source? Would it be more
    >
    > Because it is.


    Please fix your non-standard quote character to be the usual '>'.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    CBFalconer, Apr 10, 2005
    #9
  10. Ben Pfaff Guest

    CBFalconer <> writes:

    > Please fix your non-standard quote character to be the usual '>'.


    What "standard" are you referring to?
    --
    Ben Pfaff
    email:
    web: http://benpfaff.org
    Ben Pfaff, Apr 10, 2005
    #10
  11. On Sat, 9 Apr 2005, Ben Pfaff wrote:
    >
    > CBFalconer <> writes:
    >> Please fix your non-standard quote character to be the usual '>'.

    >
    > What "standard" are you referring to?


    CBFalconer used the word "standard" as part of an /adjective/, not as a
    noun. For the record, "standard" as an adjective can mean "widely
    recognized or employed," "normal, familiar, or usual," or "commonly
    used or supplied," according to the AHD. In such senses, it is perfectly
    correct to refer to ">" as "standard," and anything else (be it "#", "|",
    "quote-mark", or "not ") as "non-standard."

    -Arthur
    Arthur J. O'Dwyer, Apr 10, 2005
    #11
  12. CBFalconer Guest

    Ben Pfaff wrote:
    > CBFalconer <> writes:
    >
    >> Please fix your non-standard quote character to be the usual '>'.

    >
    > What "standard" are you referring to?


    Alright, unconventional.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    CBFalconer, Apr 10, 2005
    #12
  13. wrote:

    > 1) Why is a library a collection of compiled source-files


    Programmers usually refer to "compiled source-files" as object files
    and a collection [of related] objects files as a library archive.

    > while each header-file is a single source?


    Usually a "header-file" is used to define an *interface*
    to a *module*. The module is usually implemented
    as a collection of source files that may be stored in an archive.

    It would be perfectly correct to refer to a collection
    of related header files as a library, in which case,
    yopu might refer to the collection of headers
    as the "compile-time library" and the corresponding
    collection of object files as the "run-time library"
    whether the run-time library is linked statically or dynamically.

    > Would it be more efficient
    > if they were both either compiled or not?


    Some compilers can generate "pre-compiled" header files
    which means that the header files are read and converted
    to a data structure which is more convenient for the compiler
    to re-read. Because header files are used to define interfaces,
    they usually don't cause the compiler to emit any code
    or reserve any memory so there isn't anything to "link"
    into the executable program.

    > Could a "header-library" exist?


    Certainly. My [standard] header library is located in my computer's

    /usr/include/

    directory.

    > 2) Why do libraries have extensions .a and .so and modules .o,


    This is [UNIX] convention and may vary from one operating system
    to another.

    > which should be reserved for cc -c output?
    > Would it be better: module.m, lib.sl, lib.dl or something alike?


    Maybe. Can you find anybody who would agree?

    > Are these forms an inheritance from C's old-time or do
    > they provide a specific functionality?


    They are inherited from UNIX.
    E. Robert Tisdale, Apr 11, 2005
    #13
  14. On Sat, 9 Apr 2005 17:55:02 +0100, Chris Croughton
    <> wrote:

    > On 9 Apr 2005 08:36:16 -0700,

    <snip>
    > > Could a "header-library" exist?

    >
    > Yes, if your translation environment supports it. For instance the
    > Borland compiler has a facility to "pre-compile" header files where it
    > knows that nothing has changed. Some Unix systems have had a concept of
    > a "source library" (indeed, I believe that ar still supports this) and a
    > compiler could accept such a thing as the place where it looks for
    > header files (I don't know of any compiler which does). <snip>


    Not Unix, but the (exDEC) VMS compiler does, and I believe at least
    some IBM mainframe (OS/360 et seq ad z/OS) compilers do. The exTandem
    NonStop Guardian compilers do a kind of hybrid: you can #include a
    file (but filenames are mostly limited to 8 alphanumeric monocase*),
    or a named section of a file, or several sections. * The standard
    headers are automatically mapped stdlib.h -> STDLIBH etc. For C89 this
    is lossless; they haven't (yet?) done C99, but for C++ and POSIX the
    part before the .h is truncated if necessary. Alternatively,
    especially for user files, you can configure the mapping.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Apr 18, 2005
    #14
    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. Nimmi Srivastav

    Headers/Libraries default locations

    Nimmi Srivastav, Apr 26, 2004, in forum: C++
    Replies:
    7
    Views:
    384
    Keith Thompson
    Apr 26, 2004
  2. Nimmi Srivastav

    Headers/Libraries default locations

    Nimmi Srivastav, Apr 26, 2004, in forum: C Programming
    Replies:
    9
    Views:
    340
    Michael Wojcik
    Apr 27, 2004
  3. dont bother
    Replies:
    0
    Views:
    788
    dont bother
    Mar 3, 2004
  4. Phil
    Replies:
    4
    Views:
    666
    Gabriel Genellina
    Jan 17, 2010
  5. Ian
    Replies:
    2
    Views:
    1,931
Loading...

Share This Page