Include statements and compiler linking

Discussion in 'C Programming' started by Joe Hacker, May 7, 2010.

  1. Joe Hacker

    Joe Hacker Guest

    I have what is probably a simple question for some but the process
    escapes my understanding. I am a newbee c programmer and understand
    some of the basics but I usually just blindly follow directions.
    Unfortunatly I'm not the type of person that just does things without
    wantint to understand why I have to do certain things.

    When you make the typical C program that uses IO using the stdio.h
    header file. Why is it that the header file doesnt need to be linked
    with the -l argument, but when you are including a library from say a
    tutorial or such you also have to name the file in your compile
    command.

    Is it something to do with the Standard Library already being linked
    in with the compiler. If that is the case why do you have to include
    it in the source file. I guess I could take another stab at it and
    guess that it is because the object code is already linked in by
    default for the Standard library. I don't think it is as easy as the
    linker not knowing the PATH to the header file.

    I appreciate any help guys and look forward to be a active member of
    the list.

    Thanks
    Joe Hacker, May 7, 2010
    #1
    1. Advertising

  2. On Thu, 6 May 2010 19:33:02 -0700 (PDT), Joe Hacker
    <> wrote:

    >I have what is probably a simple question for some but the process
    >escapes my understanding. I am a newbee c programmer and understand
    >some of the basics but I usually just blindly follow directions.
    >Unfortunatly I'm not the type of person that just does things without
    >wantint to understand why I have to do certain things.
    >
    >When you make the typical C program that uses IO using the stdio.h
    >header file. Why is it that the header file doesnt need to be linked
    >with the -l argument, but when you are including a library from say a
    >tutorial or such you also have to name the file in your compile
    >command.


    Header files are never processed during the link phase.

    >
    >Is it something to do with the Standard Library already being linked
    >in with the compiler. If that is the case why do you have to include
    >it in the source file. I guess I could take another stab at it and


    The functions that make up the standard library are never included in
    the source program (unless you are actually compiling the source for
    one of those functions).

    >guess that it is because the object code is already linked in by
    >default for the Standard library. I don't think it is as easy as the
    >linker not knowing the PATH to the header file.


    Think about the contents of a header file and think about what types
    of files get processed during the link phase.

    Header files contain source code. When you #include a header file,
    the contents of that file (that collection of source code) is inserted
    into your source code at the point of the #include directive. The
    compiler then processes that code exactly the same as it processes the
    code you wrote.

    During the link phase, object modules (possibly in separate files and
    possibly in libraries) are joined together to form an executable. No
    source code is ever processed during the link phase.

    Whoever builds the implementation (the compiler, the linker, the
    standard headers, the standard library functions, etc) gets to decide
    how the data needed in the various phases is located. Usually, there
    are defaults for where to look for header files and where to look to
    resolve references to external functions. If the data you need is not
    in the default location, then you need to tell the system where the
    data is. To that end some, but only some, implementations use -i and
    -l command line arguments. There is nothing standard about these
    command line arguments. Each implementation is free to develop its
    own conventions.

    At least one popular implementation requires the -l argument if you
    reference functions declared in math.h. That is nothing more or less
    than a choice made when that implementation was being developed. Why
    they chose to handle the math functions differently than string
    functions and I/O functions and allocation functions, etc is not a
    language question but rather one about design philosophy, best asked
    in a newsgroup where the implementation is topical.

    --
    Remove del for email
    Barry Schwarz, May 7, 2010
    #2
    1. Advertising

  3. Joe Hacker

    jacob navia Guest

    Joe Hacker a écrit :
    > I have what is probably a simple question for some but the process
    > escapes my understanding. I am a newbee c programmer and understand
    > some of the basics but I usually just blindly follow directions.
    > Unfortunatly I'm not the type of person that just does things without
    > wantint to understand why I have to do certain things.
    >
    > When you make the typical C program that uses IO using the stdio.h
    > header file. Why is it that the header file doesnt need to be linked
    > with the -l argument, but when you are including a library from say a
    > tutorial or such you also have to name the file in your compile
    > command.
    >
    > Is it something to do with the Standard Library already being linked
    > in with the compiler. If that is the case why do you have to include
    > it in the source file. I guess I could take another stab at it and
    > guess that it is because the object code is already linked in by
    > default for the Standard library. I don't think it is as easy as the
    > linker not knowing the PATH to the header file.
    >
    > I appreciate any help guys and look forward to be a active member of
    > the list.
    >
    > Thanks


    The include files contain text that will be included into your program
    text as if you would have typed it in. Nothing less, nothing more. Those
    files describe the interface of the included functions and data types to
    the compiler without actually implementing them. The implementation is
    in some object file (binary compiler output) somewhere.

    When linking the program, the compilation system will add some binary
    files to the link that you haven't specified. For instance it will
    automatically add an object file that contains the code that calls the
    "main" function, also called the "startup" code.

    Many modern compilers include by default a bunch of commonly used
    libraries to avoid making the user tell the linker at each link that he
    needs the C library, since it can be assumed that if you program in C
    you will use the C library.

    Some old compilers and some unfriendly new ones force you to specify the
    math library each time you link, provoking endless problems with
    newcomers to the language that suddenly realize that sin/cos/sqrt, and
    other functions are mising and that you have to specify it with the
    cryptic -lm linker command.

    Why is that not included? Because for hysterical reasons, many many
    years ago, there was a time when computers were so slow that not
    including the math library in the link speeded up the linking process.
    Today, this doesn't take more than a microsecond more, but hysterical
    reasons are just that: HYSTERICAL.

    Some compilers like lcc-win or MSVC under windows include a lot of
    libraries automatically in the link. They suppose that if you are
    programming in windows, libraries like kernel32.lib will be used,
    together with other libraries like the one for the common controls, etc.

    Some compilers have a directive like

    #includelib "foo.lib"

    that tells the compiler to add "foo.lib" to the linking process so that
    the user doesn't need to remember adding that library to the linker
    command line.

    In any case, obviously the compilation system can't know about ALL
    possible libraries that COULD be used by your program since there are an
    infinite number of possible libraries that could exist. At SOME point
    you will need to understand that:

    (1)
    #included files are just text that describes the interface of a module
    (2)
    Libraries that contain the implementation of a module must be specified
    to the linker.

    jacob
    jacob navia, May 7, 2010
    #3
  4. In article <hs0cil$omf$>,
    jacob navia <> wrote:
    ....
    >The include files contain text that will be included into your program
    >text as if you would have typed it in. Nothing less, nothing more. Those


    This the point where a reg will chime in and say words to the effect of:

    The so-called "include files" don't need to be files, nor do
    they need to be "include"d.

    --
    > No, I haven't, that's why I'm asking questions. If you won't help me,
    > why don't you just go find your lost manhood elsewhere.


    CLC in a nutshell.
    Kenny McCormack, May 7, 2010
    #4
  5. Joe Hacker

    Tom St Denis Guest

    On May 7, 7:07 am, (Kenny McCormack) wrote:
    > In article <hs0cil$>,
    > jacob navia  <> wrote:
    > ...
    >
    > >The include files contain text that will be included into your program
    > >text as if you would have typed it in. Nothing less, nothing more. Those

    >
    > This the point where a reg will chime in and say words to the effect of:
    >
    >         The so-called "include files" don't need to be files, nor do
    >         they need to be "include"d.


    I'd like to point out the irony in that you're both a "reg" (ular pest
    that is) and you did indeed post that, thus fulfilling your own
    prophecy.

    Congrats, you're trolling yourself.

    Tom
    Tom St Denis, May 7, 2010
    #5
  6. On May 7, 2:07 pm, (Kenny McCormack) wrote:
    >
    > This the point where a reg will chime in and say words to the effect of:
    >
    >         The so-called "include files" don't need to be files, nor do
    >         they need to be "include"d.
    >

    However not infrequently a newbie will say to himself "so include
    files are C source included by the compiler in a initial
    wordprocessing pass. Now i don't really understand all theis library
    malarky. maybe the thing to do is to examine some of the includes to
    see if I can figure out what is going on".

    It's not inherently a bad stratgey, but the fact is that most include
    files for standard or third party libraries are unreadable, if not
    absent.
    Malcolm McLean, May 7, 2010
    #6
  7. Joe Hacker

    bart.c Guest

    "Joe Hacker" <> wrote in message
    news:...
    >I have what is probably a simple question for some but the process
    > escapes my understanding. I am a newbee c programmer and understand
    > some of the basics but I usually just blindly follow directions.
    > Unfortunatly I'm not the type of person that just does things without
    > wantint to understand why I have to do certain things.
    >
    > When you make the typical C program that uses IO using the stdio.h
    > header file. Why is it that the header file doesnt need to be linked
    > with the -l argument, but when you are including a library from say a
    > tutorial or such you also have to name the file in your compile
    > command.


    A 'header file' is slightly misleading. A header file in C is just an
    include file: a source file that is included in another, and typically (for
    system headers at least) just contains declarations (not actual code or data
    that requires linking).

    So an include file does not normally result in an independent object file,
    and linking such an include file is meaningless.

    > Is it something to do with the Standard Library already being linked
    > in with the compiler. If that is the case why do you have to include
    > it in the source file.


    As I understand how it works, this system seems a mess.

    There is a standard library file that needs to be linked in (either
    statically or dynamically), but the declarations needed for this are spread
    over a couple of dozen 'header files'. In my experience, no special link
    options are needed to add in this extra library.

    It's possible this standard library may be split into several files, but
    there is little correlation with system header files.

    > I guess I could take another stab at it and
    > guess that it is because the object code is already linked in by
    > default for the Standard library. I don't think it is as easy as the
    > linker not knowing the PATH to the header file.


    It's often a mystery to me too. Once a compiler setup works, it's best to
    leave well alone.

    --
    Bartc
    bart.c, May 7, 2010
    #7
  8. In article <>,
    Tom St Denis <> wrote:
    >On May 7, 7:07 am, (Kenny McCormack) wrote:
    >> In article <hs0cil$>,
    >> jacob navia  <> wrote:
    >> ...
    >>
    >> >The include files contain text that will be included into your program
    >> >text as if you would have typed it in. Nothing less, nothing more. Those

    >>
    >> This the point where a reg will chime in and say words to the effect of:
    >>
    >>         The so-called "include files" don't need to be files, nor do
    >>         they need to be "include"d.

    >
    >I'd like to point out the irony in that you're both a "reg" (ular pest
    >that is) and you did indeed post that, thus fulfilling your own
    >prophecy.


    You need to learn how to read for comprehension, boy.

    If Richard Dawkins, in the middle of some discussion, said something
    like "This is where a religious person might say: ...", would any
    sensible person think either that:

    1) RD was a religious person
    2) RD believed the religious nonsense quoted.

    Note that *you* (Mr. Tom SD Loony Tunes) might actually think such a
    thing, but again, no sensible person would.

    And yet, I could imagine some religious loony tune (akin to the
    religious loony tunes found in CLC) claiming just that. You hear about
    it from time to time in the news.

    --
    > No, I haven't, that's why I'm asking questions. If you won't help me,
    > why don't you just go find your lost manhood elsewhere.


    CLC in a nutshell.
    Kenny McCormack, May 7, 2010
    #8
  9. In article <>,
    Malcolm McLean <> wrote:
    >On May 7, 2:07 pm, (Kenny McCormack) wrote:
    >>
    >> This the point where a reg will chime in and say words to the effect of:
    >>
    >>         The so-called "include files" don't need to be files, nor do
    >>         they need to be "include"d.
    >>

    >However not infrequently a newbie will say to himself "so include
    >files are C source included by the compiler in a initial
    >wordprocessing pass. Now i don't really understand all theis library
    >malarky. maybe the thing to do is to examine some of the includes to
    >see if I can figure out what is going on".
    >
    >It's not inherently a bad stratgey, but the fact is that most include
    >files for standard or third party libraries are unreadable, if not
    >absent.


    Really? That doesn't agree with my experience.

    --
    > No, I haven't, that's why I'm asking questions. If you won't help me,
    > why don't you just go find your lost manhood elsewhere.


    CLC in a nutshell.
    Kenny McCormack, May 7, 2010
    #9
  10. Joe Hacker

    Tom St Denis Guest

    On May 7, 8:39 am, (Kenny McCormack) wrote:
    > If Richard Dawkins, in the middle of some discussion, said something
    > like "This is where a religious person might say: ...", would any
    > sensible person think either that:
    >
    >     1) RD was a religious person
    >     2) RD believed the religious nonsense quoted.


    You said "a reg" ... you post here REGULARLY, that makes you a reg.
    And you did in fact say it, even if quoted.

    Therefore, I stand by my original observation that you're trolling
    yourself.

    It'd be more like if RD said "This is where an Atheist might say, all
    religious folk are nutters." And then you can say he IS an atheist
    and he did just say that. IOW if you weren't a reg then your RD
    analogy would work, but you are a regular and you did say it.

    Tom
    Tom St Denis, May 7, 2010
    #10
  11. Joe Hacker

    Eric Sosman Guest

    On 5/6/2010 10:33 PM, Joe Hacker wrote:
    >
    > When you make the typical C program that uses IO using the stdio.h
    > header file. Why is it that the header file doesnt need to be linked
    > with the -l argument, but when you are including a library from say a
    > tutorial or such you also have to name the file in your compile
    > command.


    This is a characteristic not of the C language, but of the C
    implementation you're using. The rules of the language tell you
    how to express what the program should do, and that's "the same"
    (with some permitted variations) for all implementations. But the
    incantations that you use to tell the implementation to translate
    your source files, combine them into a program, find necessary
    libraries, and run the result are the business of the implementation,
    and implementations differ. Sometimes they differ a lot.

    Most C implementations (all that I've run into) will find at
    least some of the Standard library routines without being told
    explicitly where to look for them. This is done as a convenience
    for the programmer: Since a very large fraction of C programs will
    use the things declared in <stdio.h> and <stdlib.h> and <string.h>
    and so on, the implementation "just knows" where to look for them
    and will do so "on its own."

    For historical reasons, some implementations treat the <math.h>
    functions differently: They're found in a conventional place, but
    the place won't be searched unless you ask for it with something
    like an "-lm" flag. Others treat the <math.h> functions the same
    way they treat the <ctype.h> functions, and will find them without
    being tickled.

    No implementation I know of will automatically search user-
    defined libraries without being told to do so, although I suppose
    it's possible. The problem (from the implementation's perspective)
    is that there might be several user-defined libraries lying around,
    perhaps containing several variant versions of the same functions;
    how is the implementation to know which library it should search?
    Also, for some implementations the search order is important: If
    your program calls libFunc() and libFunc() calls atan2(), it might
    be important to search the math library after rather than before
    searching the library that contains libFunc(). Again, this is a
    problem for the implementation: How is it supposed to figure out
    which of the N! ways to search N libraries is the right one? So
    implementations usually require you to specify (somehow) which of
    your own libraries to use and what order to search them in.

    > Is it something to do with the Standard Library already being linked
    > in with the compiler. If that is the case why do you have to include
    > it in the source file. I guess I could take another stab at it and
    > guess that it is because the object code is already linked in by
    > default for the Standard library. I don't think it is as easy as the
    > linker not knowing the PATH to the header file.


    The headers like <stdio.h> and <string.h> -- and for that matter
    "mystuff.h" -- don't actually contain the functions printf() and
    strtok() and myFunc(), but only descriptions of those functions.
    "Listen up, compiler," says <stdio.h>, "I'm going to make some calls
    to a function named fgets(), which takes three parameters of these
    types and returns a value of that type." With this information the
    compiler knows what kind of code to generate when it sees an fgets()
    call in your source code, but it still doesn't know what the body of
    fgets() looks like. It goes ahead and translates your source code,
    accepting on faith that it will eventually find the compiled guts of
    an fgets() function, somewhere. You get an object file containing
    "external references" to functions (and sometimes data) that will be
    found elsewhere at link time.

    That's the "classical" style, anyhow. Some compilers do in fact
    have built-in knowledge of Standard library functions, especially
    short functions that might compile to in-line instructions instead of
    to full-strength function calls. A call to sqrt(), for example, might
    turn into an FSQRT instruction right in the middle of your code, with
    no external reference to a separate sqrt() function and no need to
    look for one in a library. But these are departures from the norm
    for the sake of optimization; for most functions (both the Standard
    library's and your own), the headers merely declare and the function
    bodies are obtained from somewhere else.

    --
    Eric Sosman
    lid
    Eric Sosman, May 7, 2010
    #11
  12. On May 6, 11:33 pm, Joe Hacker <> wrote:
    > I have what is probably a simple question for some but the process
    > escapes my understanding. I am a newbee c programmer and understand
    > some of the basics but I usually just blindly follow directions.
    > Unfortunatly I'm not the type of person that just does things without
    > wantint to understand why I have to do certain things.
    >
    > When you make the typical C program that uses IO using the stdio.h
    > header file. Why is it that the header file doesnt need to be linked
    > with the -l argument, but when you are including a library from say a
    > tutorial or such you also have to name the file in your compile
    > command.
    >
    > Is it something to do with the Standard Library already being linked
    > in with the compiler. If that is the case why do you have to include
    > it in the source file. I guess I could take another stab at it and
    > guess that it is because the object code is already linked in by
    > default for the Standard library. I don't think it is as easy as the
    > linker not knowing the PATH to the header file.
    >
    > I appreciate any help guys and look forward to be a active member of
    > the list.
    >
    > Thanks


    [File all of this under "Lies to programmers",
    i.e. it is not true, but it is a reasonable approximation]

    The implementation works more or less like this

    -you provide some c code to do something useful

    -there is function (e.g printf), that has been written by
    someone else, (they may or may not have used c)
    instead of writing this yourself you want to just
    use it. You tell the compiler how to use the code
    by including a header file

    -the compiler will then create code that correctly
    calls printf, but will not include the code
    for printf

    -the linker will create an executable by taking the
    code provided by the compiler and adding the code for
    printf. You can tell it where to find this code by
    adding an -lm option.

    Now, usually the implementation will not include the header
    files for common functions by default, but will search
    for the code to common functions by default. So if you want to
    use printf you have to #include stdio.h to tell the compiler how
    to call printf, but you do not have to -lm libc.h to tell the linker
    where to find the code for printf.

    Why the difference? Well, there are many common functions
    so if you simply #include the instructions to call any
    of them, you might make a very small source file very big.
    A simple approach is to scan the file
    first to find out which functions
    are going to be used, then go back and start again, but
    this would take time so it was not done by the first
    compilers. On the other hand, by the time the linker
    gets to things, you know which functions you want, so the linker
    only has to put the stuff you need in.

    [Could a compiler be written so as to recognize
    many common functions, and automatically include the needed
    files? Yes. Is this done? No. There are explicit rules about
    what should be done if a header file for a function is not
    included, and including the right header file could do something
    else. There is nothing to stop the compiler warning you that
    you are telling it to do something that is almost certainly not
    what you want.]

    Now, why can't the linker find every function. Well, there
    are an infinite number a possible functions, and the code
    could be anywhere, so the linker would have to do a very
    big search. Worse, the linker would often find more than
    one function with the same name. How would it know which
    one to use? So if you want to use e.g. a tutorial function,
    you have to tell the linker where to find it.

    - William Hughes
    William Hughes, May 7, 2010
    #12
  13. Joe Hacker <> writes:
    > I have what is probably a simple question for some but the process
    > escapes my understanding. I am a newbee c programmer and understand
    > some of the basics but I usually just blindly follow directions.
    > Unfortunatly I'm not the type of person that just does things without
    > wantint to understand why I have to do certain things.
    >
    > When you make the typical C program that uses IO using the stdio.h
    > header file. Why is it that the header file doesnt need to be linked
    > with the -l argument, but when you are including a library from say a
    > tutorial or such you also have to name the file in your compile
    > command.

    [...]

    Header files are compiled, not linked.

    Libraries are usually provided in two separate pieces. The header
    file, such as "foo.h", merely defines an interface. #include'ing it
    makes the declarations visible, so the compiler can generate calls
    to the library code, but it doesn't provide the code that implements
    the functionality. That code is provided by a binary file that,
    depending on the system, might be called "foo.lib", "foo.dll",
    "foo.a", "foo.so", or whatever. The compiler, when it's compiling
    *your* code, doesn't need this, but the linker, when it combines your
    code with the library code to produce an executable program, does.
    (I'm ignoring static vs. dynamic linking.)

    Typically some or all of the C standard library, including the code
    that implements the functions declared in <stdio.h>, will be used
    automatically by the linker. (Headers are never used automatically,
    so you always need to use #include explicitly.)

    So when you write ``#include <stdio.h>'', that tells the compiler
    how to generate a call to printf(), but it doesn't provide the
    implementation of printf(). That implementation is provided by
    the linker, and since it's part of the C standard library, it's
    used automatically.

    When you write ``#include foo.h'', the same thing happens --
    except that the linker doesn't know to use "foo.lib" or whatever
    it's called unless you tell it to.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 7, 2010
    #13
  14. Kenneth Brody <> writes:
    > On 5/7/2010 7:07 AM, Kenny McCormack wrote:
    >> In article<hs0cil$omf$>,
    >> jacob navia<> wrote:
    >> ....
    >>> The include files contain text that will be included into your program
    >>> text as if you would have typed it in. Nothing less, nothing more. Those

    >>
    >> This the point where a reg will chime in and say words to the effect of:
    >>
    >> The so-called "include files" don't need to be files, nor do
    >> they need to be "include"d.

    >
    > I believe that's only true for the Standard header files. It is entirely
    > possible that
    >
    > #include <stdio.h>
    >
    > will not read a file called "stdio.h" from a file somewhere on the
    > computer's filesystem and insert it as a stream of text into the current
    > source code. I will note, however, that I have never personally seen such a
    > compiler. Then again, I've never seen CHARBITS not set to 8, nor a system
    > with sizeof(int) equal to 1. That doesn't mean they don't exist.


    That's essentially correct. It's covered in more detail in C99 6.10.2.

    A directive of the form
    #include <...>
    searches for and includes a "header", which isn't necessarily be a file.
    A directive of the form
    #include "..."
    searches for and includes a "source file". If the search fails, it
    then processes it as if it read
    #include <...>

    The term "source file" strongly implies that it's an actual file,
    but it's not entirely clear what that means. It usually refers
    to the same kind of entity that can be opened with fopen(), for
    example, but it could be anything. For that matter, the compiler
    needn't be implemented in C, and its methods for reading headers
    and source files needn't have anything to do with C's stdio.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 7, 2010
    #14
  15. Joe Hacker

    spinoza1111 Guest

    On May 7, 2:39 pm, jacob navia <> wrote:
    > Joe Hacker a écrit :
    >
    >
    >
    >
    >
    > > I have what is probably a simple question for some but the process
    > > escapes my understanding. I am a newbee c programmer and understand
    > > some of the basics but I usually just blindly follow directions.
    > > Unfortunatly I'm not the type of person that just does things without
    > > wantint to understand why I have to do certain things.

    >
    > > When you make the typical C program that uses IO using the stdio.h
    > > header file. Why is it that the header file doesnt need to be linked
    > > with the -l argument, but when you are including a library from say a
    > > tutorial or such you also have to name the file in your compile
    > > command.

    >
    > > Is it something to do with the Standard Library already being linked
    > > in with the compiler. If that is the case why do you have to include
    > > it in the source file. I guess I could take another stab at it and
    > > guess that it is because the object code is already linked in by
    > > default for the Standard library. I don't think it is as easy as the
    > > linker not knowing the PATH to the header file.

    >
    > > I appreciate any help guys and look forward to be a active member of
    > > the list.

    >
    > > Thanks

    >
    > The include files contain text that will be included into your program
    > text as if you would have typed it in. Nothing less, nothing more. Those
    > files describe the interface of the included functions and data types to
    > the compiler without actually implementing them. The implementation is
    > in some object file (binary compiler output) somewhere.


    One hopes.

    Sometimes, the include files contain pure or *reinen* preprocessor
    material that doesn't correspond to object code at all. And note that
    a civilized poster will point this out to enhance the grandeur of your
    response, not to "show you're wrong". That is what a code monkey like
    Heathfield would do.

    Most generalizations have counter-examples. To the small and
    technically educated mind like that of Heathfield, the counter-example
    falsifies the generalization in all cases. Whereas truly civilized
    people such as you and I, mon cher Monsieur, know that only in logic,
    that grand tautology, are generalizations air tight and useless for
    that reason.


    >
    > When linking the program, the compilation system will add some binary
    > files to the link that you haven't specified. For instance it will
    > automatically add an object file that contains the code that calls the
    > "main" function, also called the "startup" code.
    >
    > Many modern compilers include by default a bunch of commonly used
    > libraries to avoid making the user tell the linker at each link that he
    > needs the C library, since it can be assumed that if you program in C
    > you will use the C library.
    >
    > Some old compilers and some unfriendly new ones force you to specify the
    > math library each time you link, provoking endless problems with
    > newcomers to the language that suddenly realize that sin/cos/sqrt, and
    > other functions are mising and that you have to specify it with the
    > cryptic -lm linker command.
    >
    > Why is that not included? Because for hysterical reasons, many many
    > years ago, there was a time when computers were so slow that not
    > including the math library in the link speeded up the linking process.
    > Today, this  doesn't take more than a microsecond more, but hysterical
    > reasons are just that: HYSTERICAL.


    Ah, humor, excellent, Monsieur. Clearly the springtime in Paris works
    its magic as you leave your dark chambers for the air of the
    boulevards Haussmann, and are again enchanted by la lumiere, la grande
    puissance, les femmes charmant of your fair city. As you continue to
    work on code, may you continue to repair to the plain and wandering
    air.
    >
    > Some compilers like lcc-win or MSVC under windows include a lot of
    > libraries automatically in the link. They suppose that if you are
    > programming in windows, libraries like kernel32.lib will be used,
    > together with other libraries like the one for the common controls, etc.
    >
    > Some compilers have a directive like
    >
    > #includelib "foo.lib"
    >
    > that tells the compiler to add "foo.lib" to the linking process so that
    > the user doesn't need to remember adding that library to the linker
    > command line.
    >
    > In any case, obviously the compilation system can't know about ALL
    > possible libraries that COULD be used by your program since there are an
    > infinite number of possible libraries that could exist. At SOME point
    > you will need to understand that:
    >
    > (1)
    > #included files are just text that describes the interface of a module
    > (2)
    > Libraries that contain the implementation of a module must be specified
    > to the linker.


    The #include files are the theory: the object code is the practice.
    >
    > jacob
    spinoza1111, May 9, 2010
    #15
  16. Joe Hacker

    spinoza1111 Guest

    On May 7, 11:39 pm, Kenneth Brody <> wrote:
    > On 5/7/2010 7:07 AM, Kenny McCormack wrote:
    >
    > > In article<hs0cil$>,
    > > jacob navia<>  wrote:
    > > ....
    > >> The include files contain text that will be included into your program
    > >> text as if you would have typed it in. Nothing less, nothing more. Those

    >
    > > This the point where a reg will chime in and say words to the effect of:

    >
    > >    The so-called "include files" don't need to be files, nor do
    > >    they need to be "include"d.

    >
    > I believe that's only true for the Standard header files.  It is entirely
    > possible that
    >
    >     #include <stdio.h>
    >
    > will not read a file called "stdio.h" from a file somewhere on the
    > computer's filesystem and insert it as a stream of text into the current
    > source code.  I will note, however, that I have never personally seen such a
    > compiler.  Then again, I've never seen CHARBITS not set to 8, nor a system
    > with sizeof(int) equal to 1.  That doesn't mean they don't exist.


    You guys need an International Bac class in theory of knowledge, for
    you seem to me to be regressing to a 17th century equation of
    knowledge with ignorance, like the Pirate who speaks most wisely and
    gravely, look'ee, of Sea Monsters thar be, burn me buttocks.

    "Hacker culture" is infantile regression, as witness the popularity
    amongst hackers of Creative Anachronism and re-enactment of ancient
    slaughters, and the absence of a scientific spirit.

    >
    > --
    > Kenneth Brody
    spinoza1111, May 9, 2010
    #16
  17. Joe Hacker

    Tim Rentsch Guest

    (Kenny McCormack) writes:

    > In article <hs0cil$omf$>,
    > jacob navia <> wrote:
    > ...
    >>The include files contain text that will be included into your program
    >>text as if you would have typed it in. Nothing less, nothing more. Those

    >
    > This the point where a reg will chime in and say words to the effect of:
    >
    > The so-called "include files" don't need to be files, nor do
    > they need to be "include"d.


    If the supposed statements are informative or potentially helpful,
    and also factually accurate, what is the objection to them?
    Tim Rentsch, Jun 17, 2010
    #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.
Similar Threads
  1. Neil Zanella
    Replies:
    8
    Views:
    1,157
    mfmehdi
    Oct 20, 2006
  2. Harry George
    Replies:
    6
    Views:
    356
    Bart Nessux
    Feb 23, 2004
  3. Vince
    Replies:
    12
    Views:
    731
    Martin Gregorie
    Jan 21, 2008
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    856
    Andreas Bogenberger
    Feb 22, 2008
  5. John Crichton
    Replies:
    6
    Views:
    248
    John Crichton
    Jul 12, 2010
Loading...

Share This Page