where does the header implentation get inserted

Discussion in 'C Programming' started by amit.man@gmail.com, Sep 16, 2006.

  1. Guest

    Hi, i have newbie qestion,

    when i write

    #include <somthing.h>

    the precompiler subtitue that line with the lines from "somthing.h"
    header file.
    when, where and how the compiler insert the lines in "somthing.c"
    implementation file into my source code?

    thanks
    amit
     
    , Sep 16, 2006
    #1
    1. Advertising

  2. Ian Collins Guest

    wrote:
    > Hi, i have newbie qestion,
    >
    > when i write
    >
    > #include <somthing.h>
    >
    > the precompiler subtitue that line with the lines from "somthing.h"
    > header file.
    > when, where and how the compiler insert the lines in "somthing.c"
    > implementation file into my source code?
    >

    In a typical implementation, the preprocessor generates an intermediate
    file or data stream with header's content included inline and passes
    this to the compiler.

    --
    Ian Collins.
     
    Ian Collins, Sep 16, 2006
    #2
    1. Advertising

  3. CBFalconer Guest

    wrote:
    >
    > when i write
    >
    > #include <somthing.h>
    >
    > the precompiler subtitue that line with the lines from "somthing.h"
    > header file.
    > when, where and how the compiler insert the lines in "somthing.c"
    > implementation file into my source code?


    On the fly, during reading of the source file. It need not insert
    anything, it just has to act as if it did so.

    --
    "The most amazing achievement of the computer software industry
    is its continuing cancellation of the steady and staggering
    gains made by the computer hardware industry..." - Petroski



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 17, 2006
    #3
  4. On 16 Sep 2006 14:56:36 -0700, in comp.lang.c ,
    wrote:

    >Hi, i have newbie qestion,
    >
    >when i write
    >
    >#include <somthing.h>
    >
    >the precompiler subtitue that line with the lines from "somthing.h"
    >header file.
    >when, where and how the compiler insert the lines in "somthing.c"
    >implementation file into my source code?


    It doesn't.

    If "something" is a library, the build process will try to link with
    that library to extract the machine code needed to provide the
    functions. If "something" is another source file, you will need to
    tell the compiler to compile it too, and then tell the linker to link
    it.
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Sep 17, 2006
    #4
  5. Guest

    """
    It doesn't.

    If "something" is a library, the build process will try to link with
    that library to extract the machine code needed to provide the
    functions. If "something" is another source file, you will need to
    tell the compiler to compile it too, and then tell the linker to link
    it.
    """

    how can it know if it is a library?
    does it convert somthing.h into somthing.o and look up for it?

    amit


    ho
    CBFalconer wrote:
    > wrote:
    > >
    > > when i write
    > >
    > > #include <somthing.h>
    > >
    > > the precompiler subtitue that line with the lines from "somthing.h"
    > > header file.
    > > when, where and how the compiler insert the lines in "somthing.c"
    > > implementation file into my source code?

    >
    > On the fly, during reading of the source file. It need not insert
    > anything, it just has to act as if it did so.
    >
    > --
    > "The most amazing achievement of the computer software industry
    > is its continuing cancellation of the steady and staggering
    > gains made by the computer hardware industry..." - Petroski
    >
    >
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com
     
    , Sep 17, 2006
    #5
  6. On 17 Sep 2006 03:27:17 -0700, wrote:

    >CBFalconer wrote:
    >> wrote:
    >> >
    >> > when i write
    >> >
    >> > #include <somthing.h>
    >> >
    >> > the precompiler subtitue that line with the lines from "somthing.h"
    >> > header file.
    >> > when, where and how the compiler insert the lines in "somthing.c"
    >> > implementation file into my source code?

    >>
    >> On the fly, during reading of the source file. It need not insert
    >> anything, it just has to act as if it did so.
    >>
    >> --
    >> "The most amazing achievement of the computer software industry
    >> is its continuing cancellation of the steady and staggering
    >> gains made by the computer hardware industry..." - Petroski
    >>


    Top posting fixed. Please place your response after (or interspersed
    with) the text you are responding to.

    >"""
    >It doesn't.


    It doesn't what? What is "it" that doesn't? What does "it" refer to?
    What process should "it" be performing.

    >
    >If "something" is a library, the build process will try to link with


    If "something" is a library, it cannot be the object of a #include
    directive. Libraries contain object code which will be processed by
    the linker. #include works during preprocessing and deals only with
    text that will become part of the source to be processed by the
    compiler.

    >that library to extract the machine code needed to provide the
    >functions. If "something" is another source file, you will need to
    >tell the compiler to compile it too, and then tell the linker to link
    >it.


    You do not tell the linker to link source.

    When you #include "something", the preprocessor forces the compiler,
    in a system specific manner, to process the contents of "something" at
    the point in your source where the #include directive was encountered.

    One common method of achieving this is to copy your source into a
    temporary file line by line, substituting all the lines of "something"
    instead of copying the #include line. Thus, the compiler never really
    processes the #include or the file it refers to. It sees only the
    single file resulting from the preprocessing.

    It is fairly common for headers to not include object definitions or
    executable statements. They usually consist entirely of type and
    object declarations, function prototypes, and macro definitions. In
    this case, the result of compiling this text does not produce anything
    the linker cares about.

    Even if "something" does contain executable code or object
    definitions, the result of compiling its text is part of the object
    code built from your source file. The linker know to process this
    additional object code the same way it knows to process any of your
    object code.

    >"""
    >
    >how can it know if it is a library?


    The compiler never sees a library. The #include directive does not
    refer to a library. Libraries are processed at link time. How the
    linker knows which libraries need to be searched for external
    functions your code references is system specific.

    >does it convert somthing.h into somthing.o and look up for it?


    The text from "somthing" is processed as part of your source and any
    resulting object code is part of your object file. somthing.o is a
    system specific result of processing somthing.c, not somthing.h. In
    this case, somthing.c must be the translation unit and not a #include
    file. If you compile x.c and #include "somthing.c", the resulting
    object file will be called x.o.

    Not all systems use the .o naming convention. Mine doesn't even use
    the .c convention.


    Remove del for email
     
    Barry Schwarz, Sep 17, 2006
    #6
  7. Guest

    i think my question is misunderstood.

    suppose i declare a function in "myLib.h". that function has an
    implementation - lets say
    that that implementation is in "myLib.c"

    now if i put the line #include "myLib.h" into some code, i can use the
    function of "myLib" in that code. i understand where its get the
    function declaration (it's copy the lines of myLib.h into my source
    code, in one way or another).
    what i dont understand is where it's getting the actual function
    implementation.

    thanks
    amit

    all

    Barry Schwarz wrote:
    > On 17 Sep 2006 03:27:17 -0700, wrote:
    >
    > >CBFalconer wrote:
    > >> wrote:
    > >> >
    > >> > when i write
    > >> >
    > >> > #include <somthing.h>
    > >> >
    > >> > the precompiler subtitue that line with the lines from "somthing.h"
    > >> > header file.
    > >> > when, where and how the compiler insert the lines in "somthing.c"
    > >> > implementation file into my source code?
    > >>
    > >> On the fly, during reading of the source file. It need not insert
    > >> anything, it just has to act as if it did so.
    > >>
    > >> --
    > >> "The most amazing achievement of the computer software industry
    > >> is its continuing cancellation of the steady and staggering
    > >> gains made by the computer hardware industry..." - Petroski
    > >>

    >
    > Top posting fixed. Please place your response after (or interspersed
    > with) the text you are responding to.
    >
    > >"""
    > >It doesn't.

    >
    > It doesn't what? What is "it" that doesn't? What does "it" refer to?
    > What process should "it" be performing.
    >
    > >
    > >If "something" is a library, the build process will try to link with

    >
    > If "something" is a library, it cannot be the object of a #include
    > directive. Libraries contain object code which will be processed by
    > the linker. #include works during preprocessing and deals only with
    > text that will become part of the source to be processed by the
    > compiler.
    >
    > >that library to extract the machine code needed to provide the
    > >functions. If "something" is another source file, you will need to
    > >tell the compiler to compile it too, and then tell the linker to link
    > >it.

    >
    > You do not tell the linker to link source.
    >
    > When you #include "something", the preprocessor forces the compiler,
    > in a system specific manner, to process the contents of "something" at
    > the point in your source where the #include directive was encountered.
    >
    > One common method of achieving this is to copy your source into a
    > temporary file line by line, substituting all the lines of "something"
    > instead of copying the #include line. Thus, the compiler never really
    > processes the #include or the file it refers to. It sees only the
    > single file resulting from the preprocessing.
    >
    > It is fairly common for headers to not include object definitions or
    > executable statements. They usually consist entirely of type and
    > object declarations, function prototypes, and macro definitions. In
    > this case, the result of compiling this text does not produce anything
    > the linker cares about.
    >
    > Even if "something" does contain executable code or object
    > definitions, the result of compiling its text is part of the object
    > code built from your source file. The linker know to process this
    > additional object code the same way it knows to process any of your
    > object code.
    >
    > >"""
    > >
    > >how can it know if it is a library?

    >
    > The compiler never sees a library. The #include directive does not
    > refer to a library. Libraries are processed at link time. How the
    > linker knows which libraries need to be searched for external
    > functions your code references is system specific.
    >
    > >does it convert somthing.h into somthing.o and look up for it?

    >
    > The text from "somthing" is processed as part of your source and any
    > resulting object code is part of your object file. somthing.o is a
    > system specific result of processing somthing.c, not somthing.h. In
    > this case, somthing.c must be the translation unit and not a #include
    > file. If you compile x.c and #include "somthing.c", the resulting
    > object file will be called x.o.
    >
    > Not all systems use the .o naming convention. Mine doesn't even use
    > the .c convention.
    >
    >
    > Remove del for email
     
    , Sep 17, 2006
    #7
  8. On 17 Sep 2006 03:27:17 -0700, in comp.lang.c ,
    wrote:

    >"""
    >It doesn't.
    >
    >If "something" is a library, the build process will try to link with
    >that library to extract the machine code needed to provide the
    >functions. If "something" is another source file, you will need to
    >tell the compiler to compile it too, and then tell the linker to link
    >it.
    >"""
    >
    >how can it know if it is a library?


    Because thats how it was provided to you.
    The header by itself is useless. It has to have a library or source
    file or object or something to contain the actual code.

    >does it convert somthing.h into somthing.o and look up for it?


    No.
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Sep 17, 2006
    #8
  9. In article <>,
    <> wrote:
    >i think my question is misunderstood.


    >suppose i declare a function in "myLib.h". that function has an
    >implementation - lets say
    >that that implementation is in "myLib.c"


    >now if i put the line #include "myLib.h" into some code, i can use the
    >function of "myLib" in that code. i understand where its get the
    >function declaration (it's copy the lines of myLib.h into my source
    >code, in one way or another).
    >what i dont understand is where it's getting the actual function
    >implementation.


    The language itself doesn't answer this question: the standards
    just say that external linkage -exists-, and gives very minimal properties
    for it, but does not say anything about how it works.

    In the past, there have been C implementations for which it was
    necessary to name all the source files on the compiler command line and
    which interpreted all of the lines of code as necessary, so everything
    had to be named at once..


    In every system that I have actually used, the C compiler provided
    a way to compile source seperately to some intermediate binary state,
    and the implimentation provided a mechanism to merge ("link") (possibly
    transforming greatly) the intermediate binary forms into a single
    executable. The intermediate forms have not always been machine code
    suitable for the target: sometimes they are in an assembler-style
    language that the linker rewrites into machine code.

    The answer to "where does it find the implementation of a function" then
    becomes "where-ever you tell the implementation's linker to look
    for the the intermediate file produced by the C compiler."

    It is fairly common with modern implementations that if you name
    a series of source files on a single compiler command line, that
    the compiler will automatically convert each of them to intermediate
    form and then automatically link them together to an executable.

    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
     
    Walter Roberson, Sep 17, 2006
    #9
  10. On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
    <> wrote:

    >Top posting fixed. Please place your response after (or interspersed
    >with) the text you are responding to.
    >
    >>"""
    >>It doesn't.

    >
    >It doesn't what? What is "it" that doesn't? What does "it" refer to?
    >What process should "it" be performing.


    Amit didn't say that, I did, immediately below the line where he asked
    >>when, where and how the compiler insert the lines in "somthing.c"
    >>implementation file into my source code?


    ... and thus in a context where "it" was utterly clear.

    Your "fixing" of top-posting in fact merely screwed the post up so
    that you had no idea who said what, and in relation to what.

    I suggest you start again !

    >>If "something" is a library, the build process will try to link with

    >
    >If "something" is a library, it cannot be the object of a #include
    >directive.


    Have you got a clue what you're commenting on at this point? Stop,
    wander back, and read the thread again.

    >>that library to extract the machine code needed to provide the
    >>functions. If "something" is another source file, you will need to
    >>tell the compiler to compile it too, and then tell the linker to link
    >>it.

    >
    >You do not tell the linker to link source.


    And you seem to be unable to read for sense..... (though I admit I
    used 'it' a bit too much. I could have more longwindedly said 'to link
    the results of that second compilation')

    >When you #include "something", the preprocessor forces the compiler,
    >in a system specific manner, to process the contents of "something" at
    >the point in your source where the #include directive was encountered.


    Sure, but Amit's question was - where does the compiler get the actual
    defintions of the functions from, since he _is well aware_ that
    they're not in the header.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Sep 17, 2006
    #10
  11. On Sun, 17 Sep 2006 17:49:12 +0100, Mark McIntyre
    <> wrote:

    >On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
    ><> wrote:
    >
    >>Top posting fixed. Please place your response after (or interspersed
    >>with) the text you are responding to.
    >>
    >>>"""
    >>>It doesn't.

    >>
    >>It doesn't what? What is "it" that doesn't? What does "it" refer to?
    >>What process should "it" be performing.

    >
    >Amit didn't say that, I did, immediately below the line where he asked


    Here is the beginning portion of the text of the message from amit I
    was responding to quoted from Google

    <quote>
    """
    It doesn't.

    If "something" is a library, the build process will try to link with
    that library to extract the machine code needed to provide the
    functions. If "something" is another source file, you will need to
    tell the compiler to compile it too, and then tell the linker to link
    it.
    """


    how can it know if it is a library?
    does it convert somthing.h into somthing.o and look up for it?


    amit


    ho



    - Hide quoted text -
    - Show quoted text -

    CBFalconer wrote:
    > wrote:


    > > when i write



    > > #include <somthing.h>


    </quote>

    The line you claim he didn't write is the first line in his message.
    Maybe he didn't write it and you did. But there is nothing in his
    message to indicate it came from you and not him.

    >>>when, where and how the compiler insert the lines in "somthing.c"
    >>>implementation file into my source code?

    >
    >.. and thus in a context where "it" was utterly clear.
    >
    >Your "fixing" of top-posting in fact merely screwed the post up so
    >that you had no idea who said what, and in relation to what.


    I did not move any text he attributed to you. Furthermore, I did not
    remove any attributions in his message. In fact, the only thing I
    moved was his top posting down to his first attribution. If there are
    any misattributions, they were already in his message. Nor did I
    comment on any text attributed to you.

    >
    >I suggest you start again !


    Start again from what? Text clearly marked in the original as amit's
    you claim is yours. If this is true, then my only comment is GIGO.

    >
    >>>If "something" is a library, the build process will try to link with

    >>
    >>If "something" is a library, it cannot be the object of a #include
    >>directive.

    >
    >Have you got a clue what you're commenting on at this point? Stop,
    >wander back, and read the thread again.
    >
    >>>that library to extract the machine code needed to provide the
    >>>functions. If "something" is another source file, you will need to
    >>>tell the compiler to compile it too, and then tell the linker to link
    >>>it.

    >>
    >>You do not tell the linker to link source.

    >
    >And you seem to be unable to read for sense..... (though I admit I
    >used 'it' a bit too much. I could have more longwindedly said 'to link
    >the results of that second compilation')


    amit's question appears to have been answered so I see no point in
    continuing. Since your assertions regarding authorship are
    inconsistent with the text of the message I was responding to, you're
    welcome to respond with additional ad hominems if you feel the need to
    get the last word in.


    Remove del for email
     
    Barry Schwarz, Sep 17, 2006
    #11
  12. Guest

    thank you all,
    i found this link that togther with your comments, set it right for me.

    http://www.linuxjournal.com/article/6463

    cheers
    amit


    Barry Schwarz wrote:
    > On Sun, 17 Sep 2006 17:49:12 +0100, Mark McIntyre
    > <> wrote:
    >
    > >On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
    > ><> wrote:
    > >
    > >>Top posting fixed. Please place your response after (or interspersed
    > >>with) the text you are responding to.
    > >>
    > >>>"""
    > >>>It doesn't.
    > >>
    > >>It doesn't what? What is "it" that doesn't? What does "it" refer to?
    > >>What process should "it" be performing.

    > >
    > >Amit didn't say that, I did, immediately below the line where he asked

    >
    > Here is the beginning portion of the text of the message from amit I
    > was responding to quoted from Google
    >
    > <quote>
    > """
    > It doesn't.
    >
    > If "something" is a library, the build process will try to link with
    > that library to extract the machine code needed to provide the
    > functions. If "something" is another source file, you will need to
    > tell the compiler to compile it too, and then tell the linker to link
    > it.
    > """
    >
    >
    > how can it know if it is a library?
    > does it convert somthing.h into somthing.o and look up for it?
    >
    >
    > amit
    >
    >
    > ho
    >
    >
    >
    > - Hide quoted text -
    > - Show quoted text -
    >
    > CBFalconer wrote:
    > > wrote:

    >
    > > > when i write

    >
    >
    > > > #include <somthing.h>

    >
    > </quote>
    >
    > The line you claim he didn't write is the first line in his message.
    > Maybe he didn't write it and you did. But there is nothing in his
    > message to indicate it came from you and not him.
    >
    > >>>when, where and how the compiler insert the lines in "somthing.c"
    > >>>implementation file into my source code?

    > >
    > >.. and thus in a context where "it" was utterly clear.
    > >
    > >Your "fixing" of top-posting in fact merely screwed the post up so
    > >that you had no idea who said what, and in relation to what.

    >
    > I did not move any text he attributed to you. Furthermore, I did not
    > remove any attributions in his message. In fact, the only thing I
    > moved was his top posting down to his first attribution. If there are
    > any misattributions, they were already in his message. Nor did I
    > comment on any text attributed to you.
    >
    > >
    > >I suggest you start again !

    >
    > Start again from what? Text clearly marked in the original as amit's
    > you claim is yours. If this is true, then my only comment is GIGO.
    >
    > >
    > >>>If "something" is a library, the build process will try to link with
    > >>
    > >>If "something" is a library, it cannot be the object of a #include
    > >>directive.

    > >
    > >Have you got a clue what you're commenting on at this point? Stop,
    > >wander back, and read the thread again.
    > >
    > >>>that library to extract the machine code needed to provide the
    > >>>functions. If "something" is another source file, you will need to
    > >>>tell the compiler to compile it too, and then tell the linker to link
    > >>>it.
    > >>
    > >>You do not tell the linker to link source.

    > >
    > >And you seem to be unable to read for sense..... (though I admit I
    > >used 'it' a bit too much. I could have more longwindedly said 'to link
    > >the results of that second compilation')

    >
    > amit's question appears to have been answered so I see no point in
    > continuing. Since your assertions regarding authorship are
    > inconsistent with the text of the message I was responding to, you're
    > welcome to respond with additional ad hominems if you feel the need to
    > get the last word in.
    >
    >
    > Remove del for email
     
    , Sep 17, 2006
    #12
  13. writes:
    > thank you all,
    > i found this link that togther with your comments, set it right for me.
    >
    > http://www.linuxjournal.com/article/6463


    Great.

    If you have any more questions, please remember not to top-post.
    Read <http://www.caliburn.nl/topposting.html>.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 17, 2006
    #13
  14. Default User Guest

    wrote:

    > i think my question is misunderstood.


    If you can't be bothered to pay attention to simple instructions, like
    this:

    > > Top posting fixed. Please place your response after (or
    > > interspersed with) the text you are responding to.



    Then why should we pay attention to you?





    Brian
     
    Default User, Sep 17, 2006
    #14
  15. On 17 Sep 2006 09:21:14 -0700, in comp.lang.c ,
    wrote:

    >i think my question is misunderstood.
    >
    >suppose i declare a function in "myLib.h". that function has an
    >implementation - lets say
    >that that implementation is in "myLib.c"
    >
    >now if i put the line #include "myLib.h" into some code, i can use the
    >function of "myLib" in that code. i understand where its get the
    >function declaration (it's copy the lines of myLib.h into my source
    >code, in one way or another).
    >what i dont understand is where it's getting the actual function
    >implementation.


    This is the second part of my original answer.
    You have to tell the compiler to compile both files, and then tell the
    linker to link the results together to make the executable.

    How you do this is compiler-specific. With most compilers you can
    chain the filenames together eg

    $ cc file1.c file2.c

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Sep 17, 2006
    #15
  16. David Wade Guest

    <> wrote in message
    news:...
    > i think my question is misunderstood.
    >
    > suppose i declare a function in "myLib.h". that function has an
    > implementation - lets say
    > that that implementation is in "myLib.c"
    >


    This matching of names is pure convention. For this to occur "myLib.h" must
    define a sub routine name thats also in "MyLib.c".


    > now if i put the line #include "myLib.h" into some code, i can use the
    > function of "myLib" in that code. i understand where its get the
    > function declaration (it's copy the lines of myLib.h into my source
    > code, in one way or another).
    > what i dont understand is where it's getting the actual function
    > implementation.
    >


    It gets that at the end. The source lines don't get included, the loader
    pulls the compiled modules together at the end

    > thanks
    > amit
    >
    > all
    >
    > Barry Schwarz wrote:
    > > On 17 Sep 2006 03:27:17 -0700, wrote:
    > >
    > > >CBFalconer wrote:
    > > >> wrote:
    > > >> >
    > > >> > when i write
    > > >> >
    > > >> > #include <somthing.h>
    > > >> >
    > > >> > the precompiler subtitue that line with the lines from "somthing.h"
    > > >> > header file.
    > > >> > when, where and how the compiler insert the lines in "somthing.c"
    > > >> > implementation file into my source code?
    > > >>
    > > >> On the fly, during reading of the source file. It need not insert
    > > >> anything, it just has to act as if it did so.
    > > >>
    > > >> --
    > > >> "The most amazing achievement of the computer software industry
    > > >> is its continuing cancellation of the steady and staggering
    > > >> gains made by the computer hardware industry..." - Petroski
    > > >>

    > >
    > > Top posting fixed. Please place your response after (or interspersed
    > > with) the text you are responding to.
    > >
    > > >"""
    > > >It doesn't.

    > >
    > > It doesn't what? What is "it" that doesn't? What does "it" refer to?
    > > What process should "it" be performing.
    > >
    > > >
    > > >If "something" is a library, the build process will try to link with

    > >
    > > If "something" is a library, it cannot be the object of a #include
    > > directive. Libraries contain object code which will be processed by
    > > the linker. #include works during preprocessing and deals only with
    > > text that will become part of the source to be processed by the
    > > compiler.
    > >
    > > >that library to extract the machine code needed to provide the
    > > >functions. If "something" is another source file, you will need to
    > > >tell the compiler to compile it too, and then tell the linker to link
    > > >it.

    > >
    > > You do not tell the linker to link source.
    > >
    > > When you #include "something", the preprocessor forces the compiler,
    > > in a system specific manner, to process the contents of "something" at
    > > the point in your source where the #include directive was encountered.
    > >
    > > One common method of achieving this is to copy your source into a
    > > temporary file line by line, substituting all the lines of "something"
    > > instead of copying the #include line. Thus, the compiler never really
    > > processes the #include or the file it refers to. It sees only the
    > > single file resulting from the preprocessing.
    > >
    > > It is fairly common for headers to not include object definitions or
    > > executable statements. They usually consist entirely of type and
    > > object declarations, function prototypes, and macro definitions. In
    > > this case, the result of compiling this text does not produce anything
    > > the linker cares about.
    > >
    > > Even if "something" does contain executable code or object
    > > definitions, the result of compiling its text is part of the object
    > > code built from your source file. The linker know to process this
    > > additional object code the same way it knows to process any of your
    > > object code.
    > >
    > > >"""
    > > >
    > > >how can it know if it is a library?

    > >
    > > The compiler never sees a library. The #include directive does not
    > > refer to a library. Libraries are processed at link time. How the
    > > linker knows which libraries need to be searched for external
    > > functions your code references is system specific.
    > >
    > > >does it convert somthing.h into somthing.o and look up for it?

    > >
    > > The text from "somthing" is processed as part of your source and any
    > > resulting object code is part of your object file. somthing.o is a
    > > system specific result of processing somthing.c, not somthing.h. In
    > > this case, somthing.c must be the translation unit and not a #include
    > > file. If you compile x.c and #include "somthing.c", the resulting
    > > object file will be called x.o.
    > >
    > > Not all systems use the .o naming convention. Mine doesn't even use
    > > the .c convention.
    > >
    > >
    > > Remove del for email

    >
     
    David Wade, Sep 18, 2006
    #16
    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. Lionel
    Replies:
    14
    Views:
    463
    Tom Forsmo
    Nov 15, 2006
  2. mlt
    Replies:
    2
    Views:
    892
    Jean-Marc Bourguet
    Jan 31, 2009
  3. F.R.
    Replies:
    1
    Views:
    116
    Steven D'Aprano
    Oct 4, 2013
  4. F.R.
    Replies:
    0
    Views:
    128
  5. Chris Angelico

    Re: Where does MySQLdb put inserted data?

    Chris Angelico, Oct 4, 2013, in forum: Python
    Replies:
    0
    Views:
    118
    Chris Angelico
    Oct 4, 2013
Loading...

Share This Page