关于库和标题 [英] About libraries and headers
问题描述
您好，
两个问题：
1）为什么库是已编译源文件的集合
而每个头文件都是单一来源？如果它们都是编译或不编译，它会更有效吗？
可以是标题库吗？存在吗？
2）为什么库有扩展名.a和.so和
模块.o，应保留给cc -c输出？
会不会更好：module.m，lib.sl，lib.dl或其他东西
一样吗？
这些表格是否来自C'的遗产-time或者
他们提供特定的功能吗？
Evangelos Tsoukas
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
推荐答案
2005年4月9日08:36:16 -0700， ts******@gmail.com
< ts ****** @ gmail.com>写道：
On 9 Apr 2005 08:36:16 -0700, ts******@gmail.com
<ts******@gmail.com> wrote:
两个问题：
1）为什么一个库是一个已编译的源文件的集合
而每个头文件是一个单独的源？如果它们都是编译或不编译，它会更有效吗？
图书馆不是C概念，它们是一个操作系统概念。 C
有翻译单位它可以产生一些可以执行的东西，但是那些东西是什么呢？可能不是图书馆。唯一的
"库在标准中是指定为
部分实现的函数集合，但它们可能不作为外部对象存在
''库''，例如它们可以是编译器在
处插入的代码，它们被调用（实际上有些函数通常是像优化那样实现的
）。
可以是标题库吗？存在？
是的，如果您的翻译环境支持它。例如，
Borland编译器具有预编译功能。它的头文件
知道没有任何改变。一些Unix系统有一个概念，即源库和源库。 （事实上，我相信ar仍然支持这个）和一个
编译器可以接受这样的东西，它寻找的地方
头文件（我不是知道任何编译器吗）。它甚至可以在同一个库中组合对象和源，以便
编译器可以搜索两次，一次搜索头文件，然后再搜索
找到要链接的目标文件。再一次，我不知道任何编译器
支持它。
但是，头文件包含依赖于上下文的代码，在
特别是在定义的宏上。例如，拿一个简单的
头文件：
fred.h：
#ifdef USE_DOUBLE
typedef double MyType;
#else
typedef float MyType;
#endif
根据是否定义了宏USE_DOUBLE，头文件是否包含在
中，MyType将被定义为double或float类型
（可能是因为程序员想要优化空间或
resomution）。如果它被编译，那么只有其中一个可以选择
。
2）为什么库有扩展名.a和.so和
模块.o，哪个应保留给cc -c输出？
他们不是。在某些系统上，类型分别是.lib，.dll和.obj
。但是除了编译的C
（或其他语言）输出之外，模块是什么意思？
它会更好：module.m，lib。 sl，lib.dl或类似的东西？
这些表格是C的旧版本的继承还是它们提供了特定的功能？
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?
它们由您的系统和编译器决定，仅此而已。没有标准对他们来说是没有标准的（除了他们是Unix用了很长时间的b / b $ b $时间，如果有人决定使用
不同的扩展名。）
所有这些（除了通常不编译头文件的原因）都关闭
comp.lang的主题.c，因为它与C语言无关，
它是翻译环境的一个特性（编译器，链接器，加载器，
操作系统，等等。）。你需要在一个特定于新闻组的新闻组上询问你的系统（比如Unix的comp.unix.programmer），并且可能需要
询问供应商特定的新闻组或邮件清单。
但我怀疑因为它总是以这种方式完成是一个很重要的原因
命名...
Chris C
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
ts ****** @ gmail.com 写道：
你好，
两个问题：
1）为什么库是一个已编译的源文件集合，而每个头文件都是单一来源？如果它们都是编译或不编译，它会更有效吗？
可以是标题库吗？存在？
从C *语言*的角度来看，库是一块代码
你可以使用（标准没有说明机制是什么）。
标题包含*声明*函数，外部变量和
宏（有时是预处理器指令），它们提供
信息代码使用库所必需的。
有预编译头文件的概念，但这是一个
实现细节。
2）为什么库有扩展名.a和.so和
模块.o，应该为cc -c输出保留？
它会更好：module.m ，lib.sl，lib.dl或类似的东西？
这些表格是C的旧版本的继承还是它们提供了特定的功能？
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?
所谓的文件扩展名是特定于平台的，而不是与此密切相关。
HTH，
--ag
-
Artie Gold - 德克萨斯州奥斯汀
http://it-matters.blogspot.com （新帖子12/5）
http://www.cafepress.com / goldsays
Said file extensions are platform specific and not germane here.
HTH,
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
ts ****** @ gmail .com 写道：
两个问题：
1）为什么库是编译源文件的集合
而每个头文件都是单一来源？如果它们都是编译或不编译，它会更有效吗？
可以是标题库吗？存在吗？
2）为什么库有扩展名.a和.so和
模块.o，应该为cc -c输出保留？
它会更好：module.m， lib.sl，lib.dl或类似东西？
这些表格是C的旧版继承还是它们提供了特定的功能？
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?
如何提供图书馆是个别系统控制的一个问题，而不是以任何方式对该语言进行标准化。
因此它在这里是偏离主题的。
通常将库分成小模块以避免加载和链接不需要的代码，而头文件可以指定界面
一次到大量例程。
-
"如果你想发布一个后续通过groups.google.com，不要使用
破损的回复链接在文章的底部。点击
" show options"在文章的顶部，然后点击
回复在文章标题的底部。 - Keith Thompson
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.
--
"If you want to post a followup via groups.google.com, don''t use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
这篇关于关于库和标题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
