About libraries and headers

[tsoukase]

Hello,

two questions:
1) Why is a library a collection of compiled source-files
while each header-file is a single source? Would it be more
efficient if they were both either compiled or not?
Could a "header-library" exist?
2) Why do libraries have extensions .a and .so and
modules .o, which should be reserved for cc -c output?
Would it be better: module.m, lib.sl, lib.dl or something
alike?
Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

Evangelos Tsoukas

 

[Chris Croughton]

two questions:
1) Why is a library a collection of compiled source-files
while each header-file is a single source? Would it be more
efficient if they were both either compiled or not?

Libraries aren't a C concept, they are an operating system concept. C
has "translation units" which produce something which can eventially be
executed, but what that "something" is may not be a library. The only
"library" in the standard is the collection of functions specified as
part of the implementation, but they may not exist as an external object
'library', they could for instance be code inserted by the compiler at
the point they are called (and indeed some functions are often
implemented like that for optimisation).

Could a "header-library" exist?

Yes, if your translation environment supports it. For instance the
Borland compiler has a facility to "pre-compile" header files where it
knows that nothing has changed. Some Unix systems have had a concept of
a "source library" (indeed, I believe that ar still supports this) and a
compiler could accept such a thing as the place where it looks for
header files (I don't know of any compiler which does). It would even
be possible to combine object and source in the same library so that the
compiler would search it twice, once for the header files and then to
find the object files to link. Again, I don't know of any compiler
which supports that.

However, header files contain code which depends on context, in
particular on what macros are defined. For instance, take a simple
header file:

fred.h:

#ifdef USE_DOUBLE
typedef double MyType;
#else
typedef float MyType;
#endif

Depending on whether the macro USE_DOUBLE is defined the header file is
included, MyType will be defined as either double or float types
(probably because the programmer wants to optimise for space or
resomution). If it were compiled then only one of those could be
selected.

2) Why do libraries have extensions .a and .so and
modules .o, which should be reserved for cc -c output?

They don't. On some systems the types are .lib, .dll and .obj
respecxtively. But what do you mean by 'modules' other than compiled C
(or some other language) output?

Would it be better: module.m, lib.sl, lib.dl or something
alike?
Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

They are determined by your system and compiler, nothing more. There is
no standard for them (except that they are what Unix has used for a long
time and masses of code would cease to build if someone decided to use
different extensions).

All of this (except why header files are not usually compiled) is off
topic for comp.lang.c, because it is nothing to do with C as a language,
it's a feature of the translation environment (compiler, linker, loader,
operating system, etc.). You need to ask on a newsgroup specific to
your system (comp.unix.programmer for Unix, for instance) and possibly
ask on a vendor-specific newsgroup or mailing list.

But I suspect "because it's always been done that way" is a big reason
for naming...

Chris C

 

[Artie Gold]

Hello,

two questions:
1) Why is a library a collection of compiled source-files
while each header-file is a single source? Would it be more
efficient if they were both either compiled or not?
Could a "header-library" exist?

From the standpoint of the C *language* a library is a chunk of code
you can use (and the standard does not specify what the mechanism is).
Headers contain *declarations* of functions, extern-ed variables and
macros (and sometimes preprocessor directives) that provide the
information necessary for your code to use the library.

There is the notion of "precompiled headers", but that's an
implementation detail.

2) Why do libraries have extensions .a and .so and
modules .o, which should be reserved for cc -c output?
Would it be better: module.m, lib.sl, lib.dl or something
alike?
Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

Said file extensions are platform specific and not germane here.


HTH,
--ag

 

[CBFalconer]

two questions:
1) Why is a library a collection of compiled source-files
while each header-file is a single source? Would it be more
efficient if they were both either compiled or not?
Could a "header-library" exist?
2) Why do libraries have extensions .a and .so and
modules .o, which should be reserved for cc -c output?
Would it be better: module.m, lib.sl, lib.dl or something
alike?
Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

How a library is provided is a matter for the individual system to
control, and not standardized in any way for the language.
Therefore it is off-topic here.

Often libraries are broken into small modules to avoid loading and
linking unneeded code, while header files can specify the interface
to a large number of routines at once.

 

[Joe Wright]

Hello,

two questions:
1) Why is a library a collection of compiled source-files
while each header-file is a single source? Would it be more
efficient if they were both either compiled or not?

Probably not. The library was compiled once, maybe several months or
years ago. The header is indeed source code. It is #include'd in your
program so that the compiler knows which functions you want and how to
call them from the libraries. The compiler of your prog.c cannot know
what modules or libraries will be linked into the final program.

Could a "header-library" exist?

Probably not. See comment above.

2) Why do libraries have extensions .a and .so and
modules .o, which should be reserved for cc -c output?

Because the original developers thought it was a good idea.

Would it be better: module.m, lib.sl, lib.dl or something
alike?

Probably not.

Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

Yes and yes. The file extensions are well known and exquisitely
descriptive. Your .m is already .o, .a (archive) is a static library and
..so is a shared library. No idea what you think .dl is.

Evangelos Tsoukas

Learn C. Write lots of programs. Ask questions here. Rinse. Repeat.

 

[Barry Schwarz]

Hello,

two questions:
1) Why is a library a collection of compiled source-files
while each header-file is a single source? Would it be more
efficient if they were both either compiled or not?
Could a "header-library" exist?
2) Why do libraries have extensions .a and .so and
modules .o, which should be reserved for cc -c output?
Would it be better: module.m, lib.sl, lib.dl or something
alike?
Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

Evangelos Tsoukas

You are assuming that the contents of a header file are closely
related to the contents of a library. The standard header files
describe the "user interface" to the standard functions (through the
use of function prototypes or macros), declare some standard types
(like FILE and size_t using typedef or macros), and provide access to
standard features (such as errno and stdin, commonly by macros). They
do not define how the standard functions perform their respective
tasks. For those systems that provide this, the source is usually
contained in a separate set of files which the user could use to
rebuild the functions. It is these separate files, not the headers,
which are used to build the libraries.

Header files, if they are even files at all, are used by the compiler.
Library files are used by the linker.

The contents of the standard headers are defined by the standard. The
organization of library files is an implementation detail about which
the standard says only that they exist.

For all the standard headers, compiling them would not generate any
executable code. They basically consist only of declarations and
preprocessing directives, no object definitions and no function
definitions. Try compiling a source file like
/* begin of file */
#include <stdio.h>
/* end of file */

While I don't know of any implementation to do so, there is no reason
that each library could not be the result of compiling a single source
file, though obviously not a header. Most would call this an object
file since the term library is usually used to denote a collection of
object files.


<<Remove the del for email>>

 

[tsoukase]

I think with a carefull study of your writings I can obtain anwers to
more questions of mine.
Thank you
ET

 

[SM Ryan]

(e-mail address removed) wrote:
#
# Hello,
#
# two questions:
# 1) Why is a library a collection of compiled source-files
# while each header-file is a single source? Would it be more

Because it is.

# efficient if they were both either compiled or not?

Yes, it would.

# Could a "header-library" exist?

Yes, it could. For some other languages this already the case.

C started in more primitive environment, and it is now too late to do massive
changes without breaking huge amounts of deployed code.

 

[CBFalconer]

(e-mail address removed) wrote:
#
# Hello,
#
# two questions:
# 1) Why is a library a collection of compiled source-files
# while each header-file is a single source? Would it be more

Because it is.

Please fix your non-standard quote character to be the usual '>'.

 

[Ben Pfaff]

Please fix your non-standard quote character to be the usual '>'.

What "standard" are you referring to?

 

[Arthur J. O'Dwyer]

What "standard" are you referring to?

CBFalconer used the word "standard" as part of an /adjective/, not as a
noun. For the record, "standard" as an adjective can mean "widely
recognized or employed," "normal, familiar, or usual," or "commonly
used or supplied," according to the AHD. In such senses, it is perfectly
correct to refer to ">" as "standard," and anything else (be it "#", "|",
"quote-mark", or "not ") as "non-standard."

-Arthur

 

[CBFalconer]

What "standard" are you referring to?

Alright, unconventional.

 

[E. Robert Tisdale]

1) Why is a library a collection of compiled source-files

Programmers usually refer to "compiled source-files" as object files
and a collection [of related] objects files as a library archive.

while each header-file is a single source?

Usually a "header-file" is used to define an *interface*
to a *module*. The module is usually implemented
as a collection of source files that may be stored in an archive.

It would be perfectly correct to refer to a collection
of related header files as a library, in which case,
yopu might refer to the collection of headers
as the "compile-time library" and the corresponding
collection of object files as the "run-time library"
whether the run-time library is linked statically or dynamically.

Would it be more efficient
if they were both either compiled or not?

Some compilers can generate "pre-compiled" header files
which means that the header files are read and converted
to a data structure which is more convenient for the compiler
to re-read. Because header files are used to define interfaces,
they usually don't cause the compiler to emit any code
or reserve any memory so there isn't anything to "link"
into the executable program.

Could a "header-library" exist?

Certainly. My [standard] header library is located in my computer's

/usr/include/

directory.

2) Why do libraries have extensions .a and .so and modules .o,

This is [UNIX] convention and may vary from one operating system
to another.

which should be reserved for cc -c output?
Would it be better: module.m, lib.sl, lib.dl or something alike?

Maybe. Can you find anybody who would agree?

Are these forms an inheritance from C's old-time or do
they provide a specific functionality?

They are inherited from UNIX.

 

[Dave Thompson]

On 9 Apr 2005 08:36:16 -0700, (e-mail address removed)

Yes, if your translation environment supports it. For instance the
Borland compiler has a facility to "pre-compile" header files where it
knows that nothing has changed. Some Unix systems have had a concept of
a "source library" (indeed, I believe that ar still supports this) and a
compiler could accept such a thing as the place where it looks for
header files (I don't know of any compiler which does). <snip>

Not Unix, but the (exDEC) VMS compiler does, and I believe at least
some IBM mainframe (OS/360 et seq ad z/OS) compilers do. The exTandem
NonStop Guardian compilers do a kind of hybrid: you can #include a
file (but filenames are mostly limited to 8 alphanumeric monocase*),
or a named section of a file, or several sections. * The standard
headers are automatically mapped stdlib.h -> STDLIBH etc. For C89 this
is lossless; they haven't (yet?) done C99, but for C++ and POSIX the
part before the .h is truncated if necessary. Alternatively,
especially for user files, you can configure the mapping.

- David.Thompson1 at worldnet.att.net