Header files

B

ben

Hi,
I have few doubts about header files.

Is it true that header files always have only "function declaration"
and not definition?

Next where can i find definition of functions defined in system header
files. I'm working on UNIX.

Thanx in advance.



--ben
 
C

Chris Dollin

ben said:
I have few doubts about header files.
Is it true that header files always have only "function declaration"
and not definition?

No.

But that's generally good practice, except possibly for static inline
functions (if you're using C99 or deliberately restricting yourself to
C89 implementations with that as an extension).
Next where can i find definition of functions defined in system header
files.

Why do you want them? Do you really want the definitions, or just a
description?
I'm working on UNIX.

(a) Typically those functions are described on manpages with staggeringly
obvious names.

(b) Different Unices will have those function definitions in different
places. If they ship them at all. They need not.

(c) There are publicly available sources for implementations of those
functions (note: not necessarily the ones on your Unix), eg and
in particular, glibc.

(d) Google is your nasal demon. I mean friend.
 
E

Eric Sosman

ben wrote On 11/08/06 10:23,:
Hi,
I have few doubts about header files.

Is it true that header files always have only "function declaration"
and not definition?

Usually true, but not "always" true.
Next where can i find definition of functions defined in system header
files. I'm working on UNIX.

One of the virtues of the "separate compilation" model
used by C and some other programming languages is that once
the "source code" has been compiled into "object code," you
no longer need the source: You just "link" the object code
from several compilations together, and there's your program.

Many systems take advantage of this ability to reduce the
amount of disk space needed: object code is usually much
smaller than source code, and since the object code is all
that's needed to run the program, why waste space on the
bulky source? Some Unix and non-Unix system providers may
also withhold the source code for commercial and licensing
reasons (or maybe to spare themselves embarrassment). The
upshot is that on many systems the source code won't be
present at all, or may be an "optionally installable" part
of the system distribution. On some systems, you may be
able to get the source code only by paying for it (and,
probably, by agreeing not to reveal it).

If the source for your system's libraries is available,
its location and form will be entirely system-dependent and
not dictated by the C language. (Indeed, the libraries might
not be written in C at all.) Try your question on a forum
dedicated to the particular Unix flavor you are interested in.
 
M

marora

ben said:
Hi,
I have few doubts about header files.

Is it true that header files always have only "function declaration"
and not definition?

There is no hard and fast rule which say this. However, it is the
general
practice (for very good reasons) and in some cases it is required. For
instance, if you have a static variable declared and defined in a
header
file, and you include this header file in multiple *.c files, you may
get a
compilation error.
Next where can i find definition of functions defined in system header
files. I'm working on UNIX.

I am not sure about this one, I haven't looked for the source code. I
believe, if
you have open source version of libraries, while downloading you will
need to
specify to download the source code along with the libraries.
 
J

John Bode

ben said:
Hi,
I have few doubts about header files.

Is it true that header files always have only "function declaration"
and not definition?

Not necessarily, but in general it's a good practice for several
reasons.

First of all, header files can wind up being #included multiple times
in the same translation unit (this often happens when header files
include other header files). Multiple definitions of the same function
in the same translation unit will cause the compiler to complain (it is
possible to avoid this problem with guard macros).

Secondly, if the header is included in several translation units, each
translation unit will have a redundant definition of that function.
Some linkers will resolve the redundant definitions into a single
definition, some may not. Some may complain about the redundant
definitions. If nothing else, the redundant definitions take up space.


If a function needs to be shared between multiple translation units,
it's better to put the function definition in a translation unit of its
own, compile it separately, and link it as necessary. That way, it
only needs to be compiled once (as opposed to once for every
translation unit that includes it), and you don't have to worry about
linker behavior.

Life is easiest when header files describe interfaces, not
implementations. There's really nothing stoppping you from putting a
function definition in a header file, but most of the time it will lead
to heartburn.
Next where can i find definition of functions defined in system header
files. I'm working on UNIX.

The actual source code may not be available for your implementation,
and if it is, it may vary widely between implementations. If you want
to see some examples of how the standard library functions *may* be
implemented, find P. J. Plauger's "The Standard C Library."
 
R

Richard Tobin

Is it true that header files always have only "function declaration"
and not definition?
[/QUOTE]
But that's generally good practice, except possibly for static inline
functions (if you're using C99 or deliberately restricting yourself to
C89 implementations with that as an extension).

There are also other reasonable uses of #include that are not "header
files", such as compilation units with identical parts, or ones
generated in parts.

-- Richard
 
C

Chris Dollin

But that's generally good practice, except possibly for static inline
functions (if you're using C99 or deliberately restricting yourself to
C89 implementations with that as an extension).

There are also other reasonable uses of #include that are not "header
files", such as compilation units with identical parts, or ones
generated in parts.[/QUOTE]

I'll grant that.
 

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

Forum statistics

Threads
474,078
Messages
2,570,572
Members
47,204
Latest member
MalorieSte

Latest Threads

Top