Re: About libraries and headers
- From: Chris Croughton <chris@xxxxxxxxxxxx>
- Date: Sat, 9 Apr 2005 17:55:02 +0100
On 9 Apr 2005 08:36:16 -0700, tsoukase@xxxxxxxxx
<tsoukase@xxxxxxxxx> wrote:
> 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
.
- Follow-Ups:
- Re: About libraries and headers
- From: Dave Thompson
- Re: About libraries and headers
- References:
- About libraries and headers
- From: tsoukase
- About libraries and headers
- Prev by Date: Re: Random Integers from 0 to 999
- Next by Date: Re: About libraries and headers
- Previous by thread: About libraries and headers
- Next by thread: Re: About libraries and headers
- Index(es):
Relevant Pages
|
Loading
