where does the header implentation get inserted

[amit.man@gmail.com]

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

[Ian Collins]

Re: where does the header implentation get inserted

amit.man@gmail. com 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.

[Mark McIntyre]

Re: where does the header implentation get inserted

On 16 Sep 2006 14:56:36 -0700, in comp.lang.c , amit.man@gmail. com
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 "
>implementati on 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

[CBFalconer]

Re: where does the header implentation get inserted

amit.man@gmail. com 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

[amit.man@gmail.com]

Re: where does the header implentation get inserted

"""
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:

amit.man@gmail. com 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

[Barry Schwarz]

Re: where does the header implentation get inserted

On 17 Sep 2006 03:27:17 -0700, amit.man@gmail. com wrote:

>CBFalconer wrote:

>amit.man@gmail. com 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

[amit.man@gmail.com]

Re: where does the header implentation get inserted

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, amit.man@gmail. com wrote:
>

CBFalconer wrote:

amit.man@gmail. com 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

[Walter Roberson]

Re: where does the header implentation get inserted

In article <1158510074.579 181.55760@m7g20 00cwm.googlegro ups.com>,
<amit.man@gmail .comwrote:

>i think my question is misunderstood.

>suppose i declare a function in "myLib.h". that function has an
>implementati on - 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

[Mark McIntyre]

Re: where does the header implentation get inserted

On 17 Sep 2006 03:27:17 -0700, in comp.lang.c , amit.man@gmail. com
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]

Re: where does the header implentation get inserted

On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
<schwarzb@doezl .netwrote:

>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 "
>>implementatio n 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

[Barry Schwarz]

Re: where does the header implentation get inserted

On Sun, 17 Sep 2006 17:49:12 +0100, Mark McIntyre
<markmcintyre@s pamcop.netwrote :

>On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
><schwarzb@doez l.netwrote:
>

>>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:

amit....@gmail. com 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 "
>>>implementati on 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

[amit.man@gmail.com]

Re: where does the header implentation get inserted

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
<markmcintyre@s pamcop.netwrote :
>

On Sun, 17 Sep 2006 08:22:02 -0700, in comp.lang.c , Barry Schwarz
<schwarzb@doezl .netwrote:

>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:

amit....@gmail. com 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 "
>>implementatio n 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

[Keith Thompson]

Re: where does the header implentation get inserted

amit.man@gmail. com 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_Keit h) kst-u@mib.org <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.

[Default User]

Re: where does the header implentation get inserted

amit.man@gmail. com 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

[Mark McIntyre]

Re: where does the header implentation get inserted

On 17 Sep 2006 09:21:14 -0700, in comp.lang.c , amit.man@gmail. com
wrote:

>i think my question is misunderstood.
>
>suppose i declare a function in "myLib.h". that function has an
>implementati on - 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