where does the header implentation get inserted

A

amit.man

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
 
I

Ian Collins

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.
 
C

CBFalconer

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.
 
M

Mark McIntyre

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
 
A

amit.man

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

Barry Schwarz

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
 
A

amit.man

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
 
M

Mark McIntyre

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

Walter Roberson

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.
 
M

Mark McIntyre

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


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
... 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, 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.
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
 
B

Barry Schwarz

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 -
(e-mail address removed) wrote:

</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.
.. 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.
Have you got a clue what you're commenting on at this point? Stop,
wander back, and read the thread again.


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
 
D

Default User

i think my question is misunderstood.

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


Then why should we pay attention to you?





Brian
 
M

Mark McIntyre

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
 
D

David Wade

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top